Bug 1129287 - jpackage-utils: Add support for SCL
Summary: jpackage-utils: Add support for SCL
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: jpackage-utils
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 6.7
Assignee: Java maintainers
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 1159824
TreeView+ depends on / blocked
 
Reported: 2014-08-12 13:49 UTC by Alex Wood
Modified: 2014-12-04 09:41 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-12-04 09:41:40 UTC


Attachments (Terms of Use)

Description Alex Wood 2014-08-12 13:49:55 UTC
Description of problem:

This bug is an offshoot of bug #1127346.

After enabling the mongodb24 SCL on RHEL 6.6, the `build-jar-repository` command is still unable to find the JARs installed in the SCL.

How reproducible: Always

Steps to Reproduce:
1. yum install -y mongodb24-mongo-java-driver mongodb24-runtime
2. scl enable mongodb24 -- build-jar-repository /tmp mongo

Actual results:
The command fails with the following error message: 
/usr/bin/build-jar-repository: error: Could not find mongo Java extension for this JVM
/usr/bin/build-jar-repository: error: Some specified jars were not found for this jvm

Expected results: build-jar-repository links the JAR.

Additional info: build-jar-repository is working for this test case in RHEL 7.

Comment 2 Honza Horak 2014-08-14 14:04:26 UTC
As far as I can tell there is no way to fix this in the collections unless bug #1127346 is fixed, since the following piece of code from /usr/share/java-utils/java-functions resets all necessary environment variables:
...
# Read configuration or die.
if [ -f /etc/java/java.conf ] ; then
  . /etc/java/java.conf
...

Mikolaj, can you, please, confirm my observation?

Alex, I'd like to know what is this issue breaking in your environment, so we can evaluate severity of this issue. Does this have any serious consequences for you?

Comment 3 Mikolaj Izdebski 2014-08-14 15:23:40 UTC
Java collections can (and usually do) install their own copy of javapackages-tools.  Current upstream javapackages has full support for SCLs.

By design collections should be enabled before they are used. After enabling collection which has its own copy of javapackages-tools commands like build-jar-repository should work correctly as they would be using code from scl-ized javapackages-tools.

Note that enabling collections is *currently* not needed to use build-jar-repository et al. on RHEL 7, but this may change in future.

Comment 4 Alex Wood 2014-08-14 16:42:03 UTC
> Alex, I'd like to know what is this issue breaking in your environment, so
> we can evaluate severity of this issue. Does this have any serious
> consequences for you?

The project I work on is an RPM packaged WAR file.  In the compile step, we create a temporary JAR repository containing system JARs and place it on the classpath.  During the packaging step, we symlink the system JARs into WEB-INF/lib.  That way people can rebuild the entire stack from source.  The WAR file needs the mongo.jar and bson.jar files which are in the SCL.

We have the option of using build-jar-repository and then just adding the SCL JARs it doesn't cover by hand, but obviously that's pretty brittle.  Currently I'm using some pretty serious hacks in our build.xml to handle the case.  The build.xml file creates a temporary java.conf that either overrides JAVAAPP_LIBDIR or JAVA_LIBDIR for build-jar-repository to use during its run so it will pick up the JARs in the SCL.

So for severity, I would rate it as moderate.  We can get by for the time being, but we are relying on implementation details of build-jar-repository.

Comment 5 Honza Horak 2014-08-15 12:07:34 UTC
(In reply to Mikolaj Izdebski from comment #3)
> Java collections can (and usually do) install their own copy of
> javapackages-tools.

Thanks, this is important information I was not aware of.

So, after using the bundled javapackages-tools package from RHSCL repository it really looks it works fine:

 #> rpm -q javapackages-tools
 javapackages-tools-3.4.1-1.1.el6.noarch
 #> scl enable mongodb24 -- build-jar-repository /tmp mongo ; echo $?
 0

Alex, does updating javapackages-tools solve your issue?

Comment 8 Lubos Kocman 2014-08-20 13:57:36 UTC
Hello,
javapackages-tools is not part of RHSCL. I was told that it's build only dependency which should not be shipped. Filtering happens on compose level not in brew.

Please create a bug or ticket to include javapackage-tools into rhscl, if you feel it the other way.

Thanks

Lubos

Comment 9 Honza Horak 2014-08-20 14:24:20 UTC
(In reply to Lubos Kocman from comment #8)
> Hello,
> javapackages-tools is not part of RHSCL. I was told that it's build only
> dependency which should not be shipped.

That is correct imho.

> Please create a bug or ticket to include javapackage-tools into rhscl, if
> you feel it the other way.

This is actually what should be done imho, so re-assigning to jpackage-utils, since this is a component which provides build-jar-repository in RHEL-6

Comment 17 Mikolaj Izdebski 2014-12-03 16:10:32 UTC
javapackages-tools from maven30 collection can be used as workaround as follows:

# yum install -y maven30-javapackages-tools
$ scl enable maven30 mongodb24 -- build-jar-repository /tmp mongo
$ ls -l /tmp/*mongo*
lrwxrwxrwx. 1 root root 47 Dec  3 17:07 /tmp/[mongo].jar -> /opt/rh/mongodb24/root/usr/share/java/mongo.jar

Comment 24 Bohuslav "Slavek" Kabrda 2014-12-04 09:41:40 UTC
Closing this as WONTFIX. The reasons are:

1) This feature is related to RHSCL and it is already implemented there - installing 3 additional packages from RHSCL and enabling one additional collection enables this feature (see comment 17).

2) The code that implements this feature is coming from javapackages-tools, a fork of jpackage-utils with much of the code altered or rewritten. Backporting this feature to RHEL 6 would be non-trivial and require dangerous changes.

3) This feature is available in RHEL 7, updating to RHEL 7 is another way to get the feature working.


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