11:40 p.m.
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