Bug 1247399 - Jar files are not installed according to java packaging guidelines [NEEDINFO]
Jar files are not installed according to java packaging guidelines
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: libreoffice (Show other bugs)
24
Unspecified Unspecified
unspecified Severity medium
: ---
: ---
Assigned To: David Tardon
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: 1299158 1121734
  Show dependency treegraph
 
Reported: 2015-07-27 18:37 EDT by Orion Poplawski
Modified: 2017-08-08 08:03 EDT (History)
7 users (show)

See Also:
Fixed In Version: libreoffice-5.2.1.2-2.fc25 libreoffice-5.1.5.2-5.fc24
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 08:03:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
orion: needinfo? (mizdebsk)


Attachments (Terms of Use)
Specfile patch to install jars into noarch common sub-packages (8.66 KB, patch)
2016-04-17 15:59 EDT, Orion Poplawski
no flags Details | Diff
Specfile patch to install jars into noarch common sub-packages (8.86 KB, patch)
2016-04-25 17:36 EDT, Orion Poplawski
no flags Details | Diff
Specfile patch to install jars into noarch common sub-packages (8.97 KB, patch)
2016-05-02 16:43 EDT, Orion Poplawski
no flags Details | Diff

  None (edit)
Description Orion Poplawski 2015-07-27 18:37:24 EDT
Description of problem:

libreoffice-ure installs jar files into:

/usr/lib64/libreoffice/program/classes/java_uno.jar
/usr/lib64/libreoffice/program/classes/juh.jar
/usr/lib64/libreoffice/program/classes/jurt.jar
/usr/lib64/libreoffice/program/classes/ridl.jar
/usr/lib64/libreoffice/program/classes/unoloader.jar

I'm working on trying to get jabref to compile again in Fedora and it makes use of these files.  Using the gradle system it's looking for resources under the names like 'org.openoffice:juh'.  If these file were available per the standard java packaging you would be able to do:

BuildRequires: mvn(org.openoffice:juh)

and pull in the proper rpm and make use of the jar in gradle/maven.
Comment 1 David Tardon 2015-09-07 03:30:31 EDT
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).
Comment 2 Orion Poplawski 2015-09-11 13:32:26 EDT
Mikolaj - could you please help out here?
Comment 3 Mikolaj Izdebski 2015-09-16 06:42:17 EDT
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).
Comment 4 Caolan McNamara 2016-01-20 06:22:10 EST
caolanm->sberg: if we move the jars will things "still work" ?
Comment 5 Stephan Bergmann 2016-01-20 07:50:24 EST
(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).
Comment 6 Jan Kurik 2016-02-24 10:35:56 EST
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
Comment 7 Orion Poplawski 2016-02-28 10:16:23 EST
symlinks seem like the standard way to fix such issues.  Can we get some progress here?  Thanks.
Comment 8 Stephan Bergmann 2016-02-29 04:52:09 EST
(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."
Comment 9 Orion Poplawski 2016-04-17 15:59 EDT
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.
Comment 10 David Tardon 2016-04-18 01:21:43 EDT
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.
Comment 11 Stephan Bergmann 2016-04-18 03:12:11 EDT
(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.
Comment 12 Orion Poplawski 2016-04-25 17:36 EDT
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
Comment 13 Orion Poplawski 2016-04-25 17:38:28 EDT
(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.
Comment 14 Orion Poplawski 2016-04-25 17:56:19 EDT
New scratch build (just started, hopefully succeeds): http://koji.fedoraproject.org/koji/taskinfo?taskID=13800984
Comment 15 Mikolaj Izdebski 2016-04-27 17:01:14 EDT
(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.
Comment 16 Orion Poplawski 2016-05-02 16:43 EDT
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.
Comment 17 Orion Poplawski 2016-05-19 13:47:35 EDT
Any comments before the scratch build is cleaned up?
Comment 18 Orion Poplawski 2016-08-25 18:28:50 EDT
Ping.  Comments, please?
Comment 19 Stephan Bergmann 2016-09-05 05:23:30 EDT
* 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?
Comment 20 David Tardon 2016-09-05 07:14:25 EDT
(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.
Comment 21 Orion Poplawski 2016-09-07 12:16:56 EDT
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.
Comment 22 Orion Poplawski 2016-09-07 12:17:24 EDT
BTW - Thanks for working on this, it is much appreciated.
Comment 23 Fedora Update System 2016-09-08 04:26:19 EDT
libreoffice-5.2.1.2-2.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-a0b855b6bc
Comment 24 Fedora Update System 2016-09-08 04:26:59 EDT
libreoffice-5.1.5.2-5.fc24 has been submitted as an update to Fedora 24. https://bodhi.fedoraproject.org/updates/FEDORA-2016-a492d16149
Comment 25 Orion Poplawski 2016-09-08 11:37:19 EDT
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.
Comment 26 Fedora Update System 2016-09-09 02:25:23 EDT
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
Comment 27 Fedora Update System 2016-09-12 11:28:06 EDT
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
Comment 28 Fedora Update System 2016-09-13 14:09:09 EDT
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.
Comment 29 Fedora Update System 2016-09-13 18:23:33 EDT
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.
Comment 30 Fedora End Of Life 2017-07-25 15:03:09 EDT
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.
Comment 31 Fedora End Of Life 2017-08-08 08:03:07 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.