12:16 p.m.
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.
The idea would be to be able to build an FP per channel per release.
Using a classifier to identify the channel.
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
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. 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>
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.
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.
JF.