3:32 p.m.
On Fri, Dec 4, 2020 at 12:16 PM Jean Francois Denise <jdenise(a)redhat.com>
wrote:
Hi Brian,
I have been thinking at a possible evolution of Galleon channels and
feature-pack dependencies. This has an impact at the architectural
level, and you could think that it is not an idea to follow. That is an
early idea to acquire feedback...
Having a single FP artifact that contains its channel (current) when we
want to define multiple channels (20, 21, 22, ...) seems not right. When
designing an FP one has not the ability to select the wildfly channel he
wants to depend on. He will express the dependency on
org.wildfly:wildfly-galleon-pack:22.0.0.Final that is implicitly the
default channel. This is perhaps not a common use-case, depending on
the latest wildfly is perhaps what we want.
Yes, if I wrote a feature pack B that depended on feature pack A I would
likely want my users
a) to be able to automagically update their installation when a new release
of A came out, without my having to do a new release of B
b) but, constrain what A releases are relevant to those that are from a
particular channel.
When I say 'automagically' I mean the user doesn't have to go find the A
release, or even really know A exists. So explicitly telling Galleon to
override the 'normal' A 1.0.0 in the installation with A 1.0.1, as is
possible today, does not count.
The idea would be to be able to build an FP per channel per release.
Using a classifier to identify the channel.
Are you referring here to 'classifier' as discussed in the
"Dependencies"
section of https://maven.apache.org/pom.html?
As an example, to support 2 channels (default and 22) we would create
2
FP artifacts: org.wildfly:wildfly-galleon-pack:22.0.0.Final,
org.wildfly:wildfly-galleon-pack:22:22.0.0.Final
Is ^^^ a maven coordinate? Is that :22: a known part of a maven coordinate?
When I first read this my mind got stuck on this question as something
important but I guess it doesn't matter! A classifier is a separate part of
the object model in maven tooling and is its own element in the schemas for
declaring a dependency. If ^^^ is your own shorthand that's fine, and if
it's the official way that's good to know.
The Galleon channel would be evolved to contain the classifier to
identify the correct FP artifact, so GA+classifier+version range (and
exclude/include patterns).
It would not change the syntax of the FPL, we would still use
wildfly@community-universe:22, under the hood, the
org.wildfly:wildfly-galleon-pack:22:22.0.1.Final would be retrieved with
all dependencies properly bound to the correct channels. To properly
bind the dependencies to the channel we want we need more metadata.
A new XML file to express the channels we want to build FP for is
introduced.
Why a separate file? (I'm not arguing against it; I just want to better
understand.)
This file contains mapping of the dependencies producers to
the channels to use. This new XML file would be used when building a
feature-pack. Would look like something like:
<channels>
<channel>
<name>22</name>
<dependencies>
<dependency group-id="org.wildfly.core"
artifact-id="wildfly-core-galleon-pack" channel="15">
<dependency group-id="org.wildfly"
artifact-id="wildfly-servlet-galleon-pack" channel="22">
<dependency group-id="org.wildfly"
artifact-id="wildfly-ee-galleon-pack" channel="22">
</dependencies>
<channel>
<channel>
<name>22.0</name>
<dependencies>
<dependency group-id="org.wildfly.core"
artifact-id="wildfly-core-galleon-pack" channel="15.0">
<dependency group-id="org.wildfly"
artifact-id="wildfly-servlet-galleon-pack" channel="22.0">
<dependency group-id="org.wildfly"
artifact-id="wildfly-ee-galleon-pack" channel="22.0">
</dependencies>
<channel>
</channels>
Does the pom for the feature pack's maven module still need to declare the
fixed version deps?
At the end of the build we would have 3 FP built, one for the channel
'current', one for the channel 22 and one for 22.0. Exactly the same
bits, except the dependency that contains a classifier. The default
channel would be used the way it is today (present in the
wildfly-feature-pack-build.xml file), no need to have an entry for it in
the new xml file.
I imagine there might be a desire to be able to turn that off easily.
When designing a FP that depend on wildfly, one would then be able
to
select the channel he wants to depend on by selecting the GAV (+
classifier). User could benefit from this feature and deploy multiple FP
with classifiers.
So one could then do:
install wildfly:current
install myfp:latest (that depends on latest wildfly).
or
install wildfly:22
install myfp:1.0 (that depends on channel 22 of wildfly).
or:
install wildfly:23
install myfp:2.0 (that depends on channel 23 of wildfly).
Something we would not be able to do (and can't do today is):
install wildfly:current
install myfp:2.0 (that depends on channel 23 of wildfly).
Although the myfp:2.0 would work on the latest widfly, there is no
relationship (order) between "current" and 23 channel, so we can't
identify that the installation is valid. Perhaps we need another
evolution there (compatible channels?).
So more artifacts, more constraints but seems to bring clearer
dependencies tree.
I like it.
JF.
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
--
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat