Description of problem: When you try to install rh-maven33 package from SCL you will get now big list of dependencies. That, on one side, is a problem on its own, but on the list we can find two JDK (devel) packages: java-1.7.0-openjdk-devel and java-1.8.0-openjdk-devel (with their dependencies). It looks that the rh-maven33 package has a hard dependency on java-1.7.0-openjdk-devel. This is wrong and it should use latest java-devel package. Currently this is java-1.8.0-openjdk-devel. We would end up with a single (and fresh) JDK. Having unnecessary JDK installed consumes a lot of space on the disk. This is a problem especially in the Docker world, where each image will weight about 200MB more just because of this wrong dependency. Another thing to consider are CVEs. If we ship maven from SCL and there will be a CVE affecting JDK7 we would need to respin that Docker image. As you can imagine - we would like to avoid this and cut the dependency tree where possible. Version-Release number of selected component (if applicable): rh-maven33-1-17.el7.x86_64
Created attachment 1229085 [details] maven dependencies from optional repo Attached "regular" maven dependencies on a clean RHEL 7.3 host.
Created attachment 1229086 [details] rh-maven33 dependency list Attached rh-maven33 dependencies on a clean RHEL 7.3 host.
Additional info: this issue affects all xPaaS Docker images: Red Hat JBoss Enterprise Application Platform (JBoss EAP) Red Hat JBoss BPM Suite intelligent process server Red Hat JBoss BRMS real time decision server Red Hat JBoss Data Virtualization Red Hat JBoss Fuse Integration Services Red Hat Single-Sign-On Red Hat JBoss Data Grid Red Hat JBoss Web Server (Apache Tomcat) Red Hat JBoss A-MQ As well as new images that are in development (there are a few).
+1: FIS 2.0 only wants to include Java 8 in it's images, but still use mvn 3.3
Switching metapackage requirement to "java-devel-openjdk >= 1:1.7" from "java-1.7.0-openjdk-devel" would fix this issue. We don't want to switch to requiring generic "java-devel" because it is satisfiable by non-OpenJDK, proprietary JVMs (IBM, Oracle). "java-devel-openjdk" virtual provide is available in RHEL 7.0+. In 7.0 through 7.2 it can by satisfied only by JDK 7, but since RHEL 7.3 both JDK 7 and 8 satisfy it (see bug #1216018). "java-devel-openjdk" is also available since RHEL 6.8, but it can be satisfied only by JDK 7. Summary: - can be fixed for RHEL 7, but "pure-JDK-8" installs (no JDK 7 pulled in) would require installing on RHEL 7.3 (or newer). - can't be fix on RHEL 6 because JDK 8 does not provide "java-devel-openjdk" - RHEL 6 builds can be switched to use "java-devel-openjdk" once we drop support for RHEL 6.7. Joe, what are minimal RHEL versions (6.y, 7.y) that need to supported by RHSCL 2.4?
Cloud Enablement team is (very) happy with a fix for RHEL 7.3+.
Noting that this issue impacts the upcoming release of Fuse xPaaS images for OpenShift. We would prefer to use the SCL version of Maven 3.3 in our images, but this issue currently blocks that move. I expect that this impacts all other xPaaS images as well. Diogenes can provide more detail there.
The direction is that images should have the minimal dependencies included to properly function. If there is an alternative which considers only one jdk (1.8), then I don't see why, and will not agree with both being included. Reduced image size is seen as a functional requirement due to the fact that specially in cloud environments the cost associated with shipping and storing bits may be a blocker for some users. D.
rh-maven33 can already be installed with only a single JDK as dependency - java-1.7.0-openjdk-devel. This bug is about allowing it to use any OpenJDK >= 1.7
This has boiled down to an engineering solution more than positioning and PM is about to run out of this technical breath :-) The positioning is clear: Java 1.8 applications obviously require a 1.8 JDK and the produced image should have the minimal functional components to run such image. So if maven33 can properly function with jdk 1.8, and the app is a 1.8 app, then only jdk 1.8 should be required. D.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2017:1154