eclipse
Release Data for Eclipse Collections 12.0.0
Hello1 It's been nearly 3years since 11.1.0 and 2 years since 12.0.0.M3. When will the GA version 12.0.0 be released? Thank you for this utility!
@1102145121, thank you for your question! Is there anything specifically in the 12.0.0 release you are looking for?
Regardless, we've certainly passed the point where we should just release to keep the library current, even if there are no specific feature needs from customers. I spoke with @motlin today and will speak with @nikhilnanivadekar and @prathasirisha to see when we can schedule a release date and get this to done. I hope we can get the release out maybe in a couple months, schedules permitting. I will be pushing for this, since I've been on a break for the past year and a half writing a book about Eclipse Collections up to version 11.1.0. The book is available in paperback and hardcover now, and will hopefully be available in eBook form by end of June. So while there have been no new product releases of Eclipse Collections in a while, the documentation of the API just got a huge boost!
Thank you for your question and your interest! It definitely helps to know folks are eager for updates!
While I cannot speak for the original poster of course, I can certainly name exactly what I have been waiting for: The ability to use JLink / JPackager while using this library.
org.eclipse.collections.api (and probably others) include an automatic module, which makes usage of this wonderful library impossible if you intend to deploy it with the tools mentioned above. I recall this being on the promised feature list for v12 years ago and I, personally would love an update on this, be it by @donraab or someone else.
Honestly, that is the only problem I have with this library at the moment but that one has been plaguing me and my Maven build chain for about 4 years now, ever since I updated to newer Java versions.
@EliasHeydrich Thank you for the feedback. Eclipse Collections 12.0 has successfully completed the release review process: https://projects.eclipse.org/projects/technology.collections/reviews/eclipse-collections-12.0.0-release-review
Now that the review is complete, the release itself should arrive in the next week or two courtesy of @nikhilnanivadekar.
In terms of the feature you are waiting for, I have not personally tested or confirmed JLink/JPackager compatibility with EC. It's possible that @fipro78 tested this as part of his contribution to OSGi / module support. Once the release is available, please let us know if it works as you hoped with JLink/JPackager.
The related PR from @fipro78 is here: https://github.com/eclipse-collections/eclipse-collections/pull/1569
@EliasHeydrich @donraab I created the following repository to test the different deployments with my PR.
https://github.com/fipro78/ec-consumer-test
It worked then, so if nothing has changed in the area of my PR from last year, it should work.
@fipro78 I have been having issues with the p2 release. Below is the p2 build configuration where the build is failing. Any ideas on how this can be fixed? As of now, the latest milestone releases are published to maven central but not to p2 repo.
@1102145121 @EliasHeydrich @fipro78 can you please test out the milestone versions? I will be pushing out the release this week on or around 20st June.
Please note: There are two new milestone releases pushed to maven central:
- 12.0.0.M20.JDK17 : Minimum JDK Version is Java 17
- 12.0.0.M20.JDK11 : Minimum JDK Version is Java 11
The Eclipse Collections maintainers will make a decision on if we will skip Java-11 minimum version and directly go to Java-17 or we will stick to Java-11. I am in the favor of skipping Java-11, justification is available in https://github.com/eclipse-collections/eclipse-collections/pull/1761
Thanks for your help!
@nikhilnanivadekar I will gladly help 😸
I have tested 12.0.0.M20.JDK17 as I am on Java 21 in the relevant project. I also agree with you regarding skipping Java 11, as basically everyone who is not still on Java 8 due to the nonesense that was introduced in 9 onwards, can easily upgrade to any newer version. In my humble opinion, Open Source Libs should either stay on 8 continuously (smelling a Python 2 vs 3 situation there, is Apache Tomcat still on 8?) or just embrace the newer and more annoying way of doing things in a post Java-9 world.
Regarding the test itself: I fear that I bring unfortunate news, as it does NOT work and will not, as it appears you have chosen to sign the JARs. That simply is not supported by the default Java publishing tools.
I strongly advise against that as in Java, similar to its big competitor C#/.NET, signing libraries meant for common use tends to introduce various problems when those are used in non-signed contexts. In other words, you will inadvertently restrict how "easy" your libraries are to use and integrate.
On the other hand, what exactly is gained by signing a JAR or DLL? In practice, nothing, I argue.
Your code is open source and thus accessible to all. Everyone who wants to build his or her own malicious version of the Eclipse Collections can do so. Yes, it might be signed with whatever but no one ever checks these signatures (and a --ignore-signing-information for JLink would be the average DevOp coder's standard solution if my problem arises).
Trust is instead build on factors like number-of-downloads and who uploaded something. One is better off making sure one's library is as easy-to-use and compatible as possible, as that makes it more popular, and then ensuring that one's account at places like Maven Central is protected/safe in a sensible manner. People download the first match of their search query, the one with the right name and big download numbers.
In other words, I argue you gain little but loose a lot. And few of the big popular OpenSource Java libs are signed for that reason.
Note: If the above fails to convince you, my other argument is --- Everybody who understands the issue will just fork the repo and build a non-signed version for him- or herself locally. Everyone else, students fresh into Java for instance, will just be frustrated and give up on using Eclipse Collections and that would be a shame. The TLDR; Signing your releases really brings no benefits to you.
Technically speaking, I am using org.apache.maven.plugins:maven-jlink-plugin:3.2.0:jlink (aka we have not even reached JPackager yet) and the Maven Plugin generates the following call of my project (personal data replaced):
jlink [--module-path, C:\\MyProject\\CORE\\target\\classes;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-stb\\3.3.6\\lwjgl-stb-3.3.6.jar;C:\\SomePath\\.m2\\repository\\org\\eclipse\\collections\\eclipse-collections-api\\12.0.0.M20.JDK17\\eclipse-collections-api-12.0.0.M20.JDK17.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-assimp\\3.3.6\\lwjgl-assimp-3.3.6.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl\\3.3.6\\lwjgl-3.3.6.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-openal\\3.3.6\\lwjgl-openal-3.3.6.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-lz4\\3.3.6\\lwjgl-lz4-3.3.6-natives-windows.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-stb\\3.3.6\\lwjgl-stb-3.3.6-natives-windows.jar;C:\\SomePath\\.m2\\repository\\org\\joml\\joml\\1.10.8\\joml-1.10.8.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-glfw\\3.3.6\\lwjgl-glfw-3.3.6.jar;C:\\SomePath\\.m2\\repository\\org\\eclipse\\collections\\eclipse-collections\\12.0.0.M20.JDK17\\eclipse-collections-12.0.0.M20.JDK17.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-opengl\\3.3.6\\lwjgl-opengl-3.3.6.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-opengl\\3.3.6\\lwjgl-opengl-3.3.6-natives-windows.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-openal\\3.3.6\\lwjgl-openal-3.3.6-natives-windows.jar;C:\\SomePath\\.m2\\repository\\org\\joml\\joml-primitives\\1.10.0\\joml-primitives-1.10.0.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl\\3.3.6\\lwjgl-3.3.6-natives-windows.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-assimp\\3.3.6\\lwjgl-assimp-3.3.6-natives-windows.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-glfw\\3.3.6\\lwjgl-glfw-3.3.6-natives-windows.jar;C:\\SomePath\\.m2\\repository\\org\\lwjgl\\lwjgl-lz4\\3.3.6\\lwjgl-lz4-3.3.6.jar, --add-modules, esccore,org.lwjgl.stb,org.eclipse.collections.api,org.lwjgl.assimp,org.lwjgl,org.lwjgl.openal,org.lwjgl.lz4.natives,org.lwjgl.stb.natives,org.joml,org.lwjgl.glfw,org.eclipse.collections.impl,org.lwjgl.opengl,org.lwjgl.opengl.natives,org.lwjgl.openal.natives,org.joml.primitives,org.lwjgl.natives,org.lwjgl.assimp.natives,org.lwjgl.glfw.natives,org.lwjgl.lz4, --output, C:\MyProject\CORE\target\maven-jlink\default]
Actually though, that is of little consequence. To reproduce the issues with JLink/JPackager, creating a HelloWorld that employs Eclipse Collections and then trying JLink will be sufficient.
@nikhilnanivadekar have you updated the eclipse collections version in the target file? Looks like it is still pointing to a snapshot version.
@fipro78 which file? I thought I had updated all but might have missed something or dropped a commit during the git rebasing I was doing yesterday 😃 . Just to double check all versions should be 12.0.0 or the milestone version? I’ll take a look later today. Thanks a lot for your help!
@nikhilnanivadekar IIRC I changed the p2 repo build, so it is only necessary to run that for the deployment. This simplified the build scripts for the development itself. So the p2 build is now isolated. And it consumes the artefacts from Maven. The deployment process would be then, first publish your artefacts to Maven, once they are available via Maven, update the p2 build scripts to consume those artefacts and run the p2 build. Might not be very convenient, but IIRC I thought that this way you have less impact at development time from the p2 stuff.
The p2 build uses a target platform where it is configured which items to use. There I have configured a Maven target, so it should be easy for you to update the version there.
https://github.com/eclipse-collections/eclipse-collections/blob/master/p2-feature/org.eclipse.collections.target/org.eclipse.collections.target.target
Maybe it is possible to skip the target definition and define the dependencies in the pom.xml. I will check thath.
@nikhilnanivadekar I created the following PR https://github.com/eclipse-collections/eclipse-collections/pull/1767
With this it should be easier for you to configure the p2 update site build. Basically need to update the pom.xml files in p2-feature to create the correct p2 update site. The build is now pom-first, which means no additional target file involved anymore.
Still the process would be to first publish to Maven Central, then update the pom.xml files of p2-feature to consume those artefacts, then run the p2-feature build, to create the p2 update site.
Hope that helps.
@nikhilnanivadekar I have updated my ec-consumer-test example to the latest milestone and all the consumer scenarios work as expected. With the JDK11 variant as well as with the JDK 17 variant.
@EliasHeydrich I strongly disagree to your statement that the artefacts should not be signed. And you actually explained the reason why. As an open source project anybody can checkout the code, modify it and maybe introduce malicious code, then build and publish it somehow. Without a signatur it is impossible to determine if the downloaded artefact is from the project itself or from someone else. In Java projects where JARs are consumed and used, signatures are checked. At least in commercial environments it is typically a mandatory process to check the signatures of JARs. So I don't agree to your statement but no one ever checks these signatures. In the Java world this is part of the typical release process.
All your statements like Everybody who understands the issue will just fork the repo and build a non-signed version for him- or herself locally. make me answer "well then go ahead and do it on your own risk".
I understand that regarding jlink and native compilation this is kind of annoying. And there it doesn't make much sense, because the signatures are erased, since it is not possible to have those signatures in the resulting native image. But that is not the only way of consuming a library in Java.
At the end it is a project decision, but from my perspective it should not be removed.
@fipro78 The p2-deploy using master branch ran successfully. Can you please confirm if the p2 repository works now? As in if the Eclipse side of things are fine. I am not an expert with p2. If this works, I will raise a PR for automating the pom updates.
Here are the logs for the build:
[publish-p2-repo] $ /bin/bash /tmp/jenkins8771659234450691688.sh
running command ssh [email protected] rm -rf /home/data/httpd/download.eclipse.org/collections/12.0.0.M20.JDK11
running command ssh [email protected] mkdir /home/data/httpd/download.eclipse.org/collections/12.0.0.M20.JDK11
running command ssh [email protected] ls -al /home/data/httpd/download.eclipse.org/collections
total 35900
drwxrwsr-x 39 genie.collections technology.collections 4096 Jun 16 21:24 .
drwxrwxr-x 406 root root 12288 Jun 12 15:54 ..
drwxrwsr-x 3 genie.collections technology.collections 4096 Jul 12 2019 10.0.0
drwxrwsr-x 3 genie.collections technology.collections 4096 Sep 25 2018 10.0.0.M2
drwxrwsr-x 3 genie.collections technology.collections 4096 Dec 4 2019 10.1.0
drwxrwsr-x 3 genie.collections technology.collections 4096 Nov 22 2019 10.1.0.M1
drwxrwsr-x 3 genie.collections technology.collections 4096 Nov 25 2019 10.1.0.M2
drwxrwsr-x 3 genie.collections technology.collections 4096 Feb 11 2020 10.2.0
drwxrwsr-x 3 genie.collections technology.collections 4096 Aug 7 2020 10.3.0
drwxrwsr-x 3 genie.collections technology.collections 4096 Jul 3 2020 10.3.0.M1
drwxrwsr-x 3 genie.collections technology.collections 4096 Jul 15 2020 10.3.0.M3
drwxrwsr-x 3 genie.collections technology.collections 4096 Jul 16 2020 10.3.0.M4
drwxrwsr-x 3 genie.collections technology.collections 4096 Jul 30 2020 10.3.0.M5
drwxrwsr-x 3 genie.collections technology.collections 4096 Aug 20 2020 10.4.0
drwxr-sr-x 3 genie.collections technology.collections 4096 Nov 23 2021 11.0.0
drwxrwsr-x 3 genie.collections technology.collections 4096 Nov 2 2020 11.0.0.M1
drwxrwsr-x 3 genie.collections technology.collections 4096 Mar 19 2021 11.0.0.M2
drwxrwsr-x 3 genie.collections technology.collections 4096 Jul 14 2021 11.0.0.M3
drwxrwsr-x 3 genie.collections technology.collections 4096 Oct 29 2021 11.0.0.M5
drwxrwsr-x 3 genie.collections technology.collections 4096 Nov 4 2021 11.0.0.M6
drwxr-sr-x 3 genie.collections technology.collections 4096 Jul 5 2022 11.1.0
drwxr-sr-x 3 genie.collections technology.collections 4096 Jun 21 2022 11.1.0.M1
drwxr-sr-x 3 genie.collections technology.collections 4096 Jun 28 2022 11.1.0.M2
drwxr-sr-x 3 genie.collections technology.collections 4096 Jul 17 2023 12.0.0.M2
drwxr-sr-x 2 genie.collections technology.collections 4096 Jun 16 21:24 12.0.0.M20.JDK11
drwxrwsr-x 3 genie.collections technology.collections 4096 Jun 22 2017 8.2.0
drwxrwsr-x 3 genie.collections technology.collections 4096 Sep 20 2017 9.0.0
drwxrwsr-x 3 genie.collections technology.collections 4096 Sep 13 2017 9.0.0-SNAPSHOT
drwxrwsr-x 3 genie.collections technology.collections 4096 Aug 19 2017 9.0.0.M2
drwxrwsr-x 3 genie.collections technology.collections 4096 Aug 24 2017 9.0.0.M3
drwxrwsr-x 3 genie.collections technology.collections 4096 Sep 6 2017 9.0.0.M4
drwxrwsr-x 3 genie.collections technology.collections 4096 Dec 31 2017 9.1.0
drwxrwsr-x 3 genie.collections technology.collections 4096 Dec 6 2017 9.1.0.M1
drwxrwsr-x 3 genie.collections technology.collections 4096 Dec 11 2017 9.1.0.M2
drwxrwsr-x 3 genie.collections technology.collections 4096 May 18 2018 9.2.0
drwxrwsr-x 3 genie.collections technology.collections 4096 Feb 10 2018 9.2.0.M1
-rw-rw-r-- 1 genie.collections technology.collections 9871360 Apr 8 2016 gsc-ec-converter-7.1.0.tar
-rw-rw-r-- 1 genie.collections technology.collections 8422439 Apr 8 2016 gsc-ec-converter-7.1.0.zip
-rw-rw-r-- 1 genie.collections technology.collections 9871360 May 30 2016 gsc-ec-converter-7.1.1-SNAPSHOT.tar
-rw-rw-r-- 1 genie.collections technology.collections 8422920 May 30 2016 gsc-ec-converter-7.1.1-SNAPSHOT.zip
drwxrwsr-x 2 genie.collections technology.collections 4096 Mar 31 2016 pre-release
drwxrwsr-x 2 genie.collections technology.collections 4096 Mar 24 2016 release
drwxrwsr-x 2 genie.collections technology.collections 4096 Mar 24 2016 slides
running command scp -r /home/jenkins/agent/workspace/publish-p2-repo/p2-feature/org.eclipse.collections.repository/target/repository [email protected]:/home/data/httpd/download.eclipse.org/collections/12.0.0.M20.JDK11
running command scp /home/jenkins/agent/workspace/publish-p2-repo/p2-feature/org.eclipse.collections.repository/target/p2-repository-*.zip [email protected]:/home/data/httpd/download.eclipse.org/collections/12.0.0.M20.JDK11
running command ssh [email protected] ls -al /home/data/httpd/download.eclipse.org/collections/12.0.0.M20.JDK11
total 10816
drwxr-sr-x 3 genie.collections technology.collections 4096 Jun 16 21:24 .
drwxrwsr-x 39 genie.collections technology.collections 4096 Jun 16 21:24 ..
-rw-r--r-- 1 genie.collections technology.collections 11062026 Jun 16 21:24 p2-repository-12.0.0-SNAPSHOT.zip
drwxr-xr-x 4 genie.collections technology.collections 4096 Jun 16 21:24 repository
running command ssh [email protected] mv /home/data/httpd/download.eclipse.org/collections/12.0.0.M20.JDK11/p2-repository-*.zip /home/data/httpd/download.eclipse.org/collections/12.0.0.M20.JDK11/p2-repository-12.0.0.M20.JDK11.zip
running command ssh [email protected] ls -al /home/data/httpd/download.eclipse.org/collections/12.0.0.M20.JDK11
total 10816
drwxr-sr-x 3 genie.collections technology.collections 4096 Jun 16 21:24 .
drwxrwsr-x 39 genie.collections technology.collections 4096 Jun 16 21:24 ..
-rw-r--r-- 1 genie.collections technology.collections 11062026 Jun 16 21:24 p2-repository-12.0.0.M20.JDK11.zip
drwxr-xr-x 4 genie.collections technology.collections 4096 Jun 16 21:24 repository
All DONE!!!
@nikhilnanivadekar I tested EC Kata JDK 17 tests with both milestone versions of EC. I tested EC Kata JDK 11 tests with both JDK 17 and JDK 11 with both milestone versions of EC. I test all of the Eclipse Collections Categorically tests with both milestone versions of EC using JDK 21. Thanks for all the work with the release!
The p2 repository seems to work. At least it resolves. See the attached screenshot of the Install wizard in Eclipse.
I will check an Eclipse project and try to consume it this way.