Bug 1129287

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?

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.

> 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.

(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?

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

(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

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

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.