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

[Alexey Loubyansky]

On Tue, Feb 27, 2018 at 6:43 PM, Jason Greene <jason.greene at redhat.com>
wrote:

>
> On Feb 22, 2018, at 4:41 PM, Alexey Loubyansky <
> alexey.loubyansky at redhat.com> wrote:
>
>  I could provide a default GAV coordinate resolver based on how we are
> used to define our GAVs and also let the user (project owner) provide a
> custom one.
>
>
> Ideally the specification approach we decide on is consistent across the
> family and even the universe. It’s easier IMO to look at this from a user
> interaction perspective, and to consider which source of info is
> authoritative.
>
> For initial consumption there is two ways a user will specify what they
> initially want:
>
> A) Give me the latest WildFly (latest on a given branch:classifer)
>
> B) Give me exactly this version of WildFly (e.g. WildFly 12.0.0.Final)
>
> As you mentioned earlier in the thread, even when A is used we need to
> store B so that the prov config is reproducible. Whats also interesting is
> that in most cases the user does not care what the policy details are for
> updating to the latest, they will happily accept the default, and really in
> that scenario the authoritative source is a registry artifact in  the maven
> repo, not necessarily whats in the provisioning file. The policy details
> also aren’t important for reproducibility, since the full version already
> gives you what you need. Where it would be important in the provisioning
> file is when the user has overridden the rules. As an example, just because
> a user installs 12.0.0.Beta1, doesn’t mean that from now on they always
> want betas. They might just want to try a particular beta, and then update
> back to the main stream. So to resolve the ambiguity, in any case other
> than the default, the user would have to specify the stream they are
> interested in.
>

What I want to achieve with this is make the initial choice of A) or B) not
important in a sense that if the user chose to install the latest version,
the provisioned installation will remain 100% reprodicible since the
recorded state will include specific versions of the installed
feature-packs.
And if the user choice B), i.e. to provision a specific version, then the
usual update command would still work, because the family:branch:stream is
a part of the coordinates of the initially chosen specific version.
The same applies to the dependencies of the explicitly installed
feature-packs. The dependencies will always be of specific versions to
guarantee the reproducibility of the release. But from their coordinates we
can figure out the branch and the stream they originate from. And when
executing update we can poll for dependency updates as well.
The user would be able to switch to a different stream of the same branch,
that would have to be an explicit instruction though. I think the default
stream should be final releases. If the user wants something else then it
will need to be expressed explicitly.

Switching between branches of the same family could work too. I guess that
would depend on a specific project and the compatibility between major
version releases.


> One other thing to keep in mind, from a usability perspective, is to be
> careful with using things that look like GAVs but aren’t GAVs
>

That's a good one, agreed.

Thanks,
Alexey


>
> -Jason
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20180227/91c6e97a/attachment-0001.html