3:24 p.m.
I'm describing my thinking process of understanding this in hopes that it's
helpful to others. Or that I'm all wrong and you can correct me. ;)
AIUI you want to still want to use maven and GAVs for actually pulling
items from the repo, but the additional stream info allows you to work out
how to identify other related items. So I'm a bit unclear on the
relationships of this coordinate to a GAV.
I initially thought it's
universe:family:build-id
org.jboss:wildfly:12.0.5.Beta4
That would mean though that BUILD_ID is not just unique for the branch, it
is unique for the family. That sounds wrong, as you state it's unique to
the branch.
So now I think it's
family:branch:build-id
wildfly:12:12.0.5.Beta4
One concern with that is the 'A' in the GAV is no longer something rarely
changing. In the WildFly case it would change every 3 months. This has some
implications for the process of producing the feature packs. I'm not
saying that's a show-stopper problem; more that it's something that we'll
have to be aware of as we think through the process of creating these.
Most readers can safely skip the rest of this as I'm probably getting ahead
of myself....
An example of the kind of thing I'm talking about is in the current root
pom for WildFly we have:
<project>
....
<dependencyManagement>
<dependencies>
....
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>wildfly-feature-pack</artifactId>
<type>pom</type>
<version>${project.version}</version>
</dependency>
Thereafter any other child poms that declare a dependency on that feature
pack just have
<project>
....
<dependencies>
....
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>wildfly-feature-pack</artifactId>
<type>pom</type>
</dependency>
There's no need to specify the version all over the place, as the
dependencyManagement mechanism takes care of that in a central location.
But that kind of approach doesn't work as readily when it comes to
artifactId.
One possibility is in the root pom there's
<project>
....
<properties>
<feature.pack.branch>12</feature.pack.branch>
....
<dependencyManagement>
<dependencies>
....
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>${feature.pack.branch}</artifactId>
<version>${project.version}</version>
</dependency>
And then in other child poms:
<project>
....
<dependencies>
....
<dependency>
<groupId>${project.groupId}</groupId>
<artifactId>${feature.pack.branch}</artifactId>
<type>pom</type>
</dependency>
On Wed, Feb 21, 2018 at 4:40 PM, Alexey Loubyansky <
alexey.loubyansky(a)redhat.com> wrote:
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
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat