On Feb 22, 2018, at 4:41 PM, Alexey Loubyansky
<alexey.loubyansky(a)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.
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
-Jason