It seems it should be doable to put the jars to another location and then symlink them back (or the other way around). Unfortunately I've got no idea what "standard java packaging" means. I tried to read the lengthy java packaging HOWTO, but I don't understand half of it. Is it enough just to put the jars into %{_javadir} (or a subdir of that)? Or do I need to use some magical macro incantation the HOWTO is littered with? Feel free to propose a patch (or at least an example, changing one of the jars).

Mikolaj - could you please help out here?

As I see it, there are two problems: location of JAR files and availability of Maven metadata.

The biggest problem with current JAR location is that it varies across architectures, so noarch packages can't easily symlink or locate them. Architecture-specific JAR files should be placed in %{_jnidir}, which expands to /usr/lib/java on both 32- and 64-bit systems (because Java is exempt from multilib). Does Libreoffice need to be multilib, i.e are users expected to be able to install both 32-bit and 64-bit Libreoffice at the same time? If no, then solution can be as simple as creating symlinks to /usr/lib64/libreoffice/program/classes/*.jar under %{_jnidir}. Otherwise I can think of some other solution.

The second problems is unavailability of Maven metadata. For Libreoffice JARs to be usable from Java build systems (like Maven or Gradle) there needs to be Maven metadada installed. This should be easy to fix and I can provide patch for that, once we can agree on the location of JAR files (the first problem).

caolanm->sberg: if we move the jars will things "still work" ?

(In reply to Caolan McNamara from comment #4)
> caolanm->sberg: if we move the jars will things "still work" ?

No; moving the jars would break things.

One option for merely building against the jars (instead of also using them at runtime) would be to create copies or symlinks wherever gradle/maven expect them.  When using symlinks, that might even work for runtime (but would need testing).

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

symlinks seem like the standard way to fix such issues.  Can we get some progress here?  Thanks.

(In reply to Mikolaj Izdebski from comment #3)
> The biggest problem with current JAR location is that it varies across
> architectures, so noarch packages can't easily symlink or locate them.
> Architecture-specific JAR files should be placed in %{_jnidir}, which
> expands to /usr/lib/java on both 32- and 64-bit systems (because Java is
> exempt from multilib). Does Libreoffice need to be multilib, i.e are users
> expected to be able to install both 32-bit and 64-bit Libreoffice at the
> same time? If no, then solution can be as simple as creating symlinks to
> /usr/lib64/libreoffice/program/classes/*.jar under %{_jnidir}. Otherwise I
> can think of some other solution.

There is currently nothing (at least AFAIK) that prevents users from installing and using both 32- and 64-bit LibreOffice, so a solution that takes that into account would be preferable.  Can you detail the solution you thought about, Mikolaj?


Also:

* The relevant jars that client code might want to build against are:

** package libreoffice-core:
*** program/classes/unoil.jar

** package libreoffice-officebean:
*** program/classes/officebean.jar

** package libreoffice-ure:
*** program/classes/juh.jar
*** program/classes/jurt.jar
*** program/classes/ridl.jar
*** program/classes/unoloader.jar

* Upstream LibreOffice master has some Maven-related metadata since <https://gerrit.libreoffice.org/gitweb?p=core.git;a=commit;h=1fd41f43eb73c373cb94d32d82c5fb7a7e243367> "Add build toolchain to upload LibreOffice API to Maven Central."

Created attachment 1148081 [details]
Specfile patch to install jars into noarch common sub-packages

Well, while both 32- and 64-bit versions of libreoffice-core and libreoffice-ure are available, libreoffice-core packages conflict.  I've filed bug #1327847 for that.

The jar files really should be installed into /usr/share/java/(libreoffice?)/ as they are noarch files.  There are a number of other noarch files that really should be installed into /usr/share/libreoffice.  Hopefully this could be fixed upstream.  I also noticed that libreoffice has been disabling jar repacking due to bug #465664, but should have been fixed in F18.  This is needed to make the jar files identical on the different arch builds.

The attached patch moves the jars into /usr/share/java/libreoffice and then symlinks these back to the old location.  Currently I'm only moving the jar files, but other noarch files (.rdb, etc) could be treated in the same way (which is why I called the sub-packages "common" rather than "java" or "jars".  Scratch build is here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13694685

This should then allow the java maven data to point to the /usr/share/java/libreoffice locations.

I guess you have not read comment 8 then? It does not make any sense to move _all_ jars. Most of them are internal "libraries", hardly of any use outside of libreoffice and without any API stability guarantees whatsoever.

(In reply to Orion Poplawski from comment #9)
> The attached patch moves the jars into /usr/share/java/libreoffice and then
> symlinks these back to the old location.

Various places in the LibreOffice code base use the paths of files within a LibreOffice installation to determine paths to other files within that LibreOffice installation.  Therefore, it is necessary that the files in the LibreOffice installation are true files, not symlinks to somewhere outside the LibreOffice installation.  So the symlinks need to go the other way around.

Created attachment 1150636 [details]
Specfile patch to install jars into noarch common sub-packages

This only moves the listed stable API jars to %{_javadir}/libreoffice.  Others go to %{_datadir}/libreoffice/jars

(In reply to Stephan Bergmann from comment #11)
> (In reply to Orion Poplawski from comment #9)
> > The attached patch moves the jars into /usr/share/java/libreoffice and then
> > symlinks these back to the old location.
> 
> Various places in the LibreOffice code base use the paths of files within a
> LibreOffice installation to determine paths to other files within that
> LibreOffice installation.  Therefore, it is necessary that the files in the
> LibreOffice installation are true files, not symlinks to somewhere outside
> the LibreOffice installation.  So the symlinks need to go the other way
> around.

That's fairly messed up.  The symlinks really cannot go the other way around in a multi-arch/noarch package.

New scratch build (just started, hopefully succeeds): http://koji.fedoraproject.org/koji/taskinfo?taskID=13800984

(In reply to Stephan Bergmann from comment #8)
> There is currently nothing (at least AFAIK) that prevents users from
> installing and using both 32- and 64-bit LibreOffice, so a solution that
> takes that into account would be preferable.  Can you detail the solution
> you thought about, Mikolaj?

If you really want to keep 32- and 64-bit versions installable then you could create an arch-specific subpackage (eg. libreoffice-java) which would provide symlinks (and Maven metadata). 32- and 64-bit java subpackages would conflict, but LibreOffice itself would not.

Created attachment 1153038 [details]
Specfile patch to install jars into noarch common sub-packages

Okay, I'm hoping this build succeeds as it did locally:
http://koji.fedoraproject.org/koji/taskinfo?taskID=13894361

This only moves the API jars mentioned above to %{_javadir}/libreoffice, and puts the others in /usr/share/libreoffice/jars so they can be shared.

Hopefully Mikolaj can add the needed maven metadata on top of this to libreoffice-core-common, officebean-common, and ure-common.

I don't see any evidence that the symlinking causes issues.  Please point to specific issues if there are any.  The smoketest checks definitely caught problems when the symlinks were broken.

Any comments before the scratch build is cleaned up?

Ping.  Comments, please?

* Re the symlinks pointing from /usr/lib64/libreoffice/program/classes/*.jar (instead of the other way around), it looks like we're lucky and things happen to work.  Looks like no relevant place in LO that depends on finding other files relative to a jar happens to work on the jar's realpath, so the symlinks are transparent there.  (And the symlinks pointing that way also means there's no inherent problems with supporting installations of both 32- and 64-bit LO, AFAIU.)

* Re placing even the internal jars outside /usr/lib64/libreoffice/program/classes/ (in /usr/share/libreoffice/jars/), and splitting out the various *-common RPMs I have no idea.  David, do you have any thoughts on that?

(In reply to Stephan Bergmann from comment #19)
> * Re placing even the internal jars outside
> /usr/lib64/libreoffice/program/classes/ (in /usr/share/libreoffice/jars/),
> and splitting out the various *-common RPMs I have no idea.  David, do you
> have any thoughts on that?

Yes, I do. I disagree with that split, as I fail to see its utility. I already said it in comment 10.

Having noarch common packages saves space on the mirrors - not sure if this is a big deal or not these days.

Things like jabref (which is what prompted this in the first place) may be able to depend only on the packages containing the jar files reducing dependencies - which I guess would suggest making -java sub-packages if that was desired.

BTW - Thanks for working on this, it is much appreciated.

libreoffice-5.2.1.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-a0b855b6bc

libreoffice-5.1.5.2-5.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-a492d16149

We're not quite done here yet - we still need the maven metadata added as well.  Mikolaj can you help us out here now?  Thanks.  LibreOffice does not appear to ship pom files, but maven central has some, though not completely up to date.

libreoffice-5.2.1.2-2.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-a0b855b6bc

libreoffice-5.1.5.2-5.fc24 has been pushed to the Fedora 24 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-a492d16149

libreoffice-5.2.1.2-2.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

libreoffice-5.1.5.2-5.fc24 has been pushed to the Fedora 24 stable repository. If problems still persist, please make note of it in this bug report.

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days