Testing Component Upgrades via WildFly Core
by Darran Lofthouse
For anyone who tags components that come in via WildFly Core now may be a
good time to try setting up a job using Kabir's new snapshot-ci tool to run
through both the WildFly Core and WildFly testsuites.
Coverage doesn't presently 100% match our PR CI as we have many different
profiles but does still run way more than running the default builds
locally.
The following is an example of how I kicked of a job testing our 1.x branch
of WildFly Elytron against the latest WildFly Core and WildFly:
https://github.com/wildfly/snapshot-ci/issues/9
It is very quick to take an existing issue and copy the contents and adapt
to your own projects. In my example I used the upstream branches of all
three repos to try it out but all of these could just as easily have been
my own topic branches being used for feature development.
Now that I have set up a build I will definitely try and do this
regularly at least a day or two before we plan to tag WildFly Elytron to
better check of any unintended side effects in advance.
Regards,
Darran Lofthouse.
1 year, 6 months
A possible evolution of galleon channels
by Jean Francois Denise
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.
1 year, 6 months
