<div dir="ltr"><div>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&#39;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.</div><div><br></div><div>Until this moment I&#39;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.</div><div><br></div><div>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&#39;t fit as well.</div><div><br></div><div>What I would like to achieve is to combine the static and dynamic parts of the config into one. Here is what I&#39;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.</div><div><br></div><div>The meaning behind the parts.</div><div><br></div><div>UNIVERSE</div><div><br></div><div>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.</div><div><br></div><div>FAMILY</div><div><br></div><div>The family part would designate the project or product.</div><div><br></div><div>BRANCH</div><div><br></div><div>The branch would normally be a major version. The assumption is that anything that comes from the branch is API and config backward compatible.</div><div><br></div><div>CLASSIFIER</div><div><br></div><div>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.</div><div><br></div><div>BUILD ID</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>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.</div><div><br></div><div>If you see any problem with this approach or have a better idea, please share. Thanks!</div><div><br></div><div>Alexey</div></div>