[wildfly-dev] new feature-pack repo coords, id and streams

Alexey Loubyansky alexey.loubyansky at redhat.com
Wed Feb 21 17:40:02 EST 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180221/db00fa1d/attachment.html 


More information about the wildfly-dev mailing list