This project is for packaging third-party libraries. However, these dependencies are only present as group/artifact/version tuples in the pom.xml files. They get eventually resolved, and repackaged by JCrypTool CI and made available through Eclipse P2 update sites so the core repository can link them via the Eclipse RCP "Target platform" feature. Please refer to that repository for how we license JCT code. In this repository, we specifically express no notion of ownership or copyright to the libraries referenced by and eventually repackaged through the Maven pom.xml files. All rights when in doubt are with the authors of these libraries.
The update sites URLs of this project are currently:
- https://simlei.github.io/org.jcryptool.thirdparty/site/jre
- https://simlei.github.io/org.jcryptool.thirdparty/site/m2bundle
They are made available through the "GitHub Pages" service.
Impression of the p2 update sites in practice:
This project serves the JCrypTool (JCT) project. JCT is an Eclipse Rich Client Platform application. It requires Java artifacts (JARs) to be provided as OSGi bundles. Often, these can be found on the Eclipse Orbit update sites. However, some times this is not enough. This issue which describes the situation from which this project is used: jcryptool/core#150. The use cases are currently:
- Migration from Java 8 to Java 11: We missed javax.xml functionality which was removed from the JDK between those versions. The Orbit bundles were outdated (javax.xml 2.2), however, we required an API from 2.3 upward.
- Bugfixes of Eclipse platform libraries (as incubation before they ideally end up upstream and we don't need them anymore)
Another use case is the delivery of jlink-generated JRE features to not carry their raw binaries around in our source repositories.
To that end, two solutions are possible:
- build and package those JARs and features "by hand" and keep those manually-generated artifacts in our core repository
- depend on Maven to do all this work for us with mechanical repeatability.
Now, 1) is a manual and laborious process for each new artifact or update thereof and prone to errors. 2) is of course desirable, but requires a LOT of pom.xml files.
For 2), many ways seem possible with what the Eclipse PDE with its Maven project natures seems to suggest. For multiple reasons, all but one are unsatisfactory if one wants to use a CI server and the Eclipse PDE build to produce near-identical output. This is best explained here in an analysis of five approaches and here. In a nutshell:
- we need Maven Tycho to build our product, pom.xml based
- there are built-in solutions to work with Maven artifacts in an Eclipse product Tycho build
- ... but these "solutions" are merely tacked on hastily to enable local workflows and are not suitable for deploying a product in a sane way and fall apart when leaving either the workspace PDE build or the Maven reactor build.
In the linked analysis articles, a solution emerges via multiple Maven plugins. As a result, this project implements this approach in what I think is the best, most sane and principled way to go about it.
- the JAXB bundle shows how dependencies are defined: https://github.com/simlei/org.jcryptool.thirdparty/blob/791bf07f96169ea3a849e1741e40bd99cc3a9375/projects/org.jcryptool.thirdparty.m2bundle.jaxb/pom.xml#L21-L34
- Either we add a "misc. dependencies" project like the JAXB project (without a specific topic; where such ) where we can just put another set of these
<dependency>tags - Or, clone the JAXB project, adapt the artifact id, add it as
<module>in https://github.com/simlei/org.jcryptool.thirdparty/blob/791bf07f96169ea3a849e1741e40bd99cc3a9375/projects/pom.xml, and add it as a dependency here: https://github.com/simlei/org.jcryptool.thirdparty/blob/791bf07f96169ea3a849e1741e40bd99cc3a9375/releng/org.jcryptool.thirdparty.m2bundle.p2/pom.xml as such: https://github.com/simlei/org.jcryptool.thirdparty/blob/791bf07f96169ea3a849e1741e40bd99cc3a9375/releng/org.jcryptool.thirdparty.m2bundle.p2/pom.xml#L27-L29 - Then, just run
bin/build-alland thenbin/publish-p2-m2bundle
Just a very rough overview, because it might still be subject to change:
- The directory projects hosts the definitions of what we want to deliver in p2 update site
- The directory releng hosts the definitions of the p2 update sites
- The root pom.xml serves as parent to all other pom.xml -- except for releng/org.jcryptool.thirdparty.configuration/pom.xml, which is the uber-top pom.xml with the central configuration values which go everywhere.
- We build currently two p2 update sites:
- m2bundle -- this resolves and repackages m2
<dependencies>fully automated as fat jars, complete with allMETA-INFmetadata intoreleng/o.j.t.m2bundle.p2/target/repository. This p2 site gets built and published currently through the scriptsbin/build-allandbin/publish-p2-m2bundle; please refer to these bash scripts for the details. The build and packaging is achieved using the Apache Felix plug-in and the the excellent p2-maven-plugin by @reficio. - jre -- this builds three JRE features and publishes them as update site. For this task, the tools that come with Tycho were completely sufficient, as opposed to m2bundle. This p2 site gets built and published currently through the scripts
bin/build-allandbin/publish-p2-jre. Please refer to these bash scripts for the details.
- m2bundle -- this resolves and repackages m2
- Apache Maven - no introduction needed
- Apache Felix Maven plugin - packages a Maven project including its dependencies as a bundle and additionally shades the packaged dependencies.
- p2-maven-plugin - resolves Maven artifacts (as generated by the Felix plugin) and packages them as an Eclipse P2 update site
- Eclipse Jetty Maven plugin - Hosts the p2 update site locally (e.g. https://localhost:8080/site)