As many of you know we are planning to move to the new feature-packs and the provisioning mechanism for our wildfly(-based) distributions. New feature-packs will be artifacts in a repository (currently Maven). In this email I'd like to raise a question about how to express a location (coordinates) of a feature-pack, its identify (id) and a stream information which is the source of version updates and patches.

Until this moment I've used the GAV (group, artifact, version) as both the feature-pack ID and its coordinates in the repository. This is pretty much enough for a static installation config (which is a list of feature-pack GAVs and config options). The GAV-based config also makes the installation build reproducible. Which is a hard requirement for the provisioning mechanism.

On the other hand, we also want to be able to check for the updates in the repository for the installed feature-packs and apply them to an existing installation. Which means that the installation has to be also described in terms of the consumed update streams. This will be a description of the installation in terms of sources of the latest available versions. A build from this kind of config is not guaranteed to be reproducible. This is where the GAVs don't fit as well.

What I would like to achieve is to combine the static and dynamic parts of the config into one. Here is what I'm considering. When I install a feature-pack (using a tool or adding it manually into the installation config) what ends up in the config is the following expression: universe:family:branch:classifier:build_id, e.g. org.jboss:wildfly:12:beta:12.0.5.Beta4. This expression is going to be the feature-pack coordinates.

The meaning behind the parts.

UNIVERSE

Universe is supposed to be a registry of feature-pack streams for various projects and products. In the example above the org.jboss universe would include wildfly-core, wildfly and related projects that are consumed by wildfly that also choose to provide feature-packs.

FAMILY

The family part would designate the project or product.

BRANCH

The branch would normally be a major version. The assumption is that anything that comes from the branch is API and config backward compatible.

CLASSIFIER

Branch + classifier is what identifies a stream. The idea is that there could be multiple streams originating from the same branch. I.e. a stream of final releases, a stream of betas, alphas, etc. A user could choose which stream to subscribe to by providing the classifier.

BUILD ID

In most cases that would be the release version. universe:family:branch:build_id is going to be the feature-pack identity. The classifier is not taken into account because the same feature-pack build/release might appear in more than one stream. And so the build_id must be unique for the branch.

Given the full feature-pack coordinates, the target feature-pack can unmistakenly be identified and the installation can be reproduced. At the same time, the coordinates include the stream information, so a tool can check the stream for the updates, apply them and update the installation config with the new feature-pack build_id.

If you see any problem with this approach or have a better idea, please share. Thanks!

Alexey