Skip to content

Third party libraries for the JCT project: P2 update site generation, packaging

Notifications You must be signed in to change notification settings

grthor/org.jcryptool.thirdparty

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

57 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

JCrypTool third party libraries target platform components

License notice

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:

They are made available through the "GitHub Pages" service.

Impression of the p2 update sites in practice:

core target platform with these update sites in use

Purpose

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:

  1. build and package those JARs and features "by hand" and keep those manually-generated artifacts in our core repository
  2. 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.

How to add more Maven Central <dependencies>

Basic structure of how it works

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 all META-INF metadata into releng/o.j.t.m2bundle.p2/target/repository. This p2 site gets built and published currently through the scripts bin/build-all and bin/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-all and bin/publish-p2-jre. Please refer to these bash scripts for the details.

Used software

Related Tutorials

About

Third party libraries for the JCT project: P2 update site generation, packaging

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Java 55.8%
  • Roff 42.9%
  • Other 1.3%