Stephan: thought you might be interested in this one since it concerns SDK/Java

(In reply to Alexander Veit from comment #0)
> 1.) The Class-Path declaration in the respective META-INF/MANIFEST.MF files
> contains ../ as an entry. This does not make sense and has the potential to
> screw up IDEs and runtime deployments by adding completely unrelated parts
> of the file system to the class path[1]. It may also qualify as a security
> issue.

Those entries are necessary so that native code used by those jars can be found.

> 2.) Class-Path also contains entries like "ridl.jar unoloader.jar". This
> does not make sense either. These JARs normally do not extist since they are
> usually distributed[2] with a version suffix in the file name, e.g.
> ridl-6.4.3.jar.

Those entries are necessary because the jars use classes from those other jars.  And those other jars do have fixed names ridl.jar, unoloader.jar, etc., and are located in the LibreOffice installation's classes/ directory.

(The LibreOffice jars were never designed to be made available via Maven, outside the context of a LibreOffice installation.  I know that there have been efforts to make them available via Maven, but do not know how effective the results of those efforts were.  I personally know next to nothing about Maven.)

> Those entries are necessary so that native code used by those jars can be found.

The usual way to provide a class path for a JVM instance is that the caller specifies the class path to be uses before the JVM is started.

When JARs try to pull in dependencies on their own they do not play nicely together with other libraries the same JVM.

Currently we're manually removing the offending entries from the JARs after download and manage the patched libraries on our own.  However, this is not the way Maven is supposed to work. ;-)


> The LibreOffice jars were never designed to be made available via Maven,
> outside the context of a LibreOffice installation.

We use the libraries to utilize LibreOffice/OpenOffice as backend service for rendering documents.  I hope that such use cases are also supported by the LibreOffice Java API.


> I know that there have been efforts to make them available via Maven,
> but do not know how effective the results of those efforts were.
> I personally know next to nothing about Maven.

The LibreOffice/OpenOffice libraries have been published and regularly updated via Maven since 2007:

https://mvnrepository.com/artifact/org.libreoffice
https://mvnrepository.com/artifact/org.openoffice

(In reply to Alexander Veit from comment #3)
> > Those entries are necessary so that native code used by those jars can be found.
> 
> The usual way to provide a class path for a JVM instance is that the caller
> specifies the class path to be uses before the JVM is started.
> 
> When JARs try to pull in dependencies on their own they do not play nicely
> together with other libraries the same JVM.

That's not my understanding of how jars are supposed to work, but then again my understanding of the Java ecosystem is rather rusty and may be of no use here.  Adding Noel and Samule in cc, maybe they can add something.

> > The LibreOffice jars were never designed to be made available via Maven,
> > outside the context of a LibreOffice installation.
> 
> We use the libraries to utilize LibreOffice/OpenOffice as backend service
> for rendering documents.  I hope that such use cases are also supported by
> the LibreOffice Java API.

The "official" way is to access the jars provided by a LibreOffice installation via the SDK, see <https://api.libreoffice.org/>.

> > I know that there have been efforts to make them available via Maven,
> > but do not know how effective the results of those efforts were.
> > I personally know next to nothing about Maven.
> 
> The LibreOffice/OpenOffice libraries have been published and regularly
> updated via Maven since 2007:
> 
> https://mvnrepository.com/artifact/org.libreoffice
> https://mvnrepository.com/artifact/org.openoffice

I assume that those have always been provided on an "appears to happen to work (more or less?)" basis.

(What may also be of interest here is the combined libreoffice.jar in LO 7.0, see <https://wiki.documentfoundation.org/ReleaseNotes/7.0#Java_support>.)

Yeah, I am afraid whoever publishes those things to Maven will need to publish something a little different to the jars that we ship in our SDK, they are clearly not able to fulfill both functions.


Unfortunately, I have no idea who is actually doing the publishing.

Cloph does the publishing as part of the release process.

So the classpath needs to be adjusted for the jars published on Maven.

Additionally, the com.sun.star.comp.helper.Bootstrap class does not work on Maven, as the program directory can't be found to start LO. So that needs adjusting too.

I also got issues with the "../" in the Class-Path attribute in the manifest META-INF/MANIFEST.MF. even in the latest version libreoffice-7.1.1.jar.

The reasoning behind the "../" is beyond my understanding.
>Those entries are necessary so that native code used by those jars can be found.

Shouldn't be native code loaded from java.library.path instead of java.class.path?

Otherwise I can only ask for it:
Please hold the user responsible if native code should be used.
If you want to support your users you could prepare the executables with the 

jvm parameter example for windows:
just your native code:
-Djava.library.path="lib/dlls"

also libraries from the Operating System:
-Djava.library.path="%PATH%;lib/dlls"

Dear Alexander Veit,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug