Community
Participate
Working Groups
the build seems to call maven-compiler-plugin this will fail when running with java 17 as java 6 (default) will no longer be supported is there anything that speaks against setting maven.compiler.source/target find . -name "*.java" -type f | grep -v /target/ ./xml/org.jdom2_2.0.6/src/main/java/org/jdom2/util/NamespaceStack.java ./github/mongodb/org.eclipse.orbit.mongodb_3.2.2/src/main/java/com/mongodb/connection/GSSAPIAuthenticator.java ./apache/batik/org.apache.batik.dom_1.9.1/src/main/java/org/w3c/dom/ElementTraversal.java ./apache/batik/org.apache.batik.bridge_1.9.1/src/main/java/org/w3c/dom/Window.java ./apache/batik/org.apache.batik.bridge_1.9.1/src/main/java/org/w3c/dom/Location.java i can see that the class version then gets changed java 8 too so i assume we cannot support these bundles while running with java 17
i assume we can avoid this by configuring toolchains. the question is what is the best practice to do it. are there ones available in tbe build?
@Roland - I have been trying to handle all the Orbit stuff, but I don't understand this issue sufficiently. Can you comment?
With orbit-recipes, we are generally extracting artifacts and simply modifying the MANIFEST.MF with which they ship. That's the general case. However, there are very rare circumstances where we do a little more than that. Let's take the example of mongodb-java-driver 3.2.2 from above. They released a small change to fix a bug, but it was not backported into 3.2.2, or any other version at that time. https://github.com/mongodb/mongo-java-driver/commit/ca2f1979dfeb6c1f1eb02fb771791bbe4b8a6bd4 However, by simply adding the updated source file under the source folder at the correct location, we can update the sources for what we ship. Obviously this is less than ideal as we are not shipping the same release as upstream. https://git.eclipse.org/r/c/orbit/orbit-recipes/+/86970 The orbit-recipes build knows how to handle this : 20:44:45 [INFO] --- maven-compiler-plugin:3.8.1:compile (default-compile) @ org.eclipse.orbit.mongodb --- 20:44:45 [INFO] Changes detected - recompiling the module! 20:44:45 [INFO] Compiling 1 source file to /home/jenkins/agent/workspace/orbit-recipes/github/mongodb/org.eclipse.orbit.mongodb_3.2.2/target/classes I see a maven-compiler-plugin definition in releng/mavenparent/pom.xml so I suspect that's what needs to be modified. It's probably an older version and it's default source/target level is 1.6. I would first try bumping it up (3.9.0?) to see if that fixes it to use something higher. If that doesn't work, you can always force the source/target level you want with https://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html#source
the problem is the jars we patch are java 6 classes so having newer ones e.g. by setting maven.compiler.source/target might break them. with the toolchains we can run the build with java 11 or 17 and use java 8 as provider to compile against java 6
(In reply to Christian Dietrich from comment #4) > the problem is the jars we patch are java 6 classes > so having newer ones > e.g. > by setting maven.compiler.source/target might break them. > with the toolchains we can run the build with java 11 or 17 > and use java 8 as provider to compile against java 6 Right, then I think the only option is to try updating to a newer version of the mongodb-java-driver. One whose class files are compiled against a higher level of Java.
but what about batik and jdom they might have same problem
I think I am following now. I propose that going forward we stop accepting such patched third party bundles in Orbit. As for the bundles that have .java files today: - mongo The latest 3.x version has the fix applied and it passes license check with clearlydefined, so I propose we remove the 3.2.2 and change to 3.12.10 https://search.maven.org/artifact/org.mongodb/mongo-java-driver/3.12.10/jar - jdom They have just recently release 2.0.6.1 which includes the fix (an IP code copying issue) and a CVE fix. The 2.0.6.1 also passes license check (due to it being a patch update compared to the CQ) https://search.maven.org/artifact/org.jdom/jdom2/2.0.6.1/jar - batik Lets remove the 1.9.1 version of batik altogether. There is 1.14.0 version in Orbit for a while already. Both 1.9.1 and 1.14.0 are in SimRel, the 1.9.1 comes from graphiti only and ideally there is only supposed to be one version of each library in simrel so this problem needs resolving anyway. If you are ok with the above I will provide the gerrits.
> If you are ok with the above I will provide the gerrits. @Christian - ping. Do we need this change for 2022-06?
Don’t seem to get bugzilla mails. No we don’t need it for 2022 06
The Eclipse Orbit project is now on GitHub at https://github.com/eclipse/orbit If this issue is still relevant, please create an issue (and PR :-) on GitHub. This notice is only going to the 17 bugzilla's that have been changed in the last ~18 months or so to avoid inundating everyone's inbox with long out of date issues. Please see https://bugs.eclipse.org/bugs/buglist.cgi?product=Orbit&query_format=advanced&resolution=--- for all the unresolved Orbit bugs
