6:21 p.m.
I've been experimenting with some changes to how dependency management
works in main. The motivation is 3-fold:
1) Make it easier to build and test alternative versions of WF (e.g. WF
Preview).
2) Let us move faster on converting standard WF to jakarta.* by making it
easier to swap the dependencies used by one of our maven modules.
3) Make progress on clarifying the bill of materials used to build and test
WF. Some projects use our root pom as a bom, and it's not designed for that
purpose. I don't think any of the poms in the wildfly/wildfly repo are
meant to be used as a bom, but I expect people will do so anyway, so we're
better off having more formalized dependency management. It will help our
own work in the long run too, I think.
#2 is for sure the main short term motivation.
The key problem we have is that the bulk of our dependency management is in
the root pom. That's convenient because all child modules automatically
inherit it, but it makes using alternate dependency sets problematic. In
particular, trying to override dependency versions in profiles doesn't work
well. You end up having to redeclare the maven version for anything you
use. Importing some other pom (e.g. ee-9/pom.xml to get the WFP dependency
set) doesn't work. This has proven to be a hassle with
testsuite/integration/microprofile-tck and testuite/preview.
Here's what I propose to do, as shown in a draft pr at [1]:
1) Centralize the version properties in the root pom. (This is already in
place in main.) This meant moving the WFP version override properties out
of ee-9/pom.xml and into the root. There are a couple advantages:
a) All these properties are centralized in one pom, which is more
understandable for future development and maintenance.
b) The properties are visible in all children, regardless of profile in use
etc.
The impact of this is that if WF Preview has a specific version of
something, the dependencyManagement entry for it uses a different property,
${preview.version.org.foo} instead of ${version.org.foo}. That's actually
more understandable though.
2) (Perhaps) Create a 'common' bom pom for dependencies where std WF and
WFP are using the same dep to provide a particular API. My current work
still uses the root pom for these, which is less work right now and might
be fine long term. Moving them out into a separate pom would help clarify
to others that the root pom is no longer in any way a bom.
3) An 'ee' bom for standard WildFly dependencies that get installed via the
wildfly-ee feature pack and that are not used in WFP. A module can import
this pom into its dependencyManagement and get all the deps needed for
building or testing the non-MP aspects of WF. Currently to progress
without deciding where to place/what to call this pom artifact I'm using
the ee-feature-pack/pom.xml (parent to various child modules to produce the
'wildfly-ee' FP) for this. This depends on the 'common' bom and thus
includes all its artifacts in its dependencyManagement.
4) A 'wildfly' bom that imports the 'ee' bom and adds the other std WF
deps
that differ from WFP. A module can import this pom into its
dependencyManagement and get all the deps needed for building or testing
std WF. Currently to progress without deciding where to place/what to call
this pom artifact I'm using the galleon-pack/pom.xml (parent to various
child modules to produce the 'wildfly' FP) for this.
5) An 'wildfly-preview' bom for WildFly Preview dependencies that differ
from standard WF. A module can import this pom into its
dependencyManagement and get all the deps needed for building or testing
WFP. Currently to progress without deciding where to place/what to call
this pom artifact I'm using the ee-9/pom.xml (parent to various child
modules to produce WFP) for this. This depends on the 'common' bom and thus
includes all its artifacts in its dependencyManagement.
The 'ee', 'wildfly' and 'wildfly-preview' boms can each be
imported to get
a complete dependency set for some variant of WF. In the testsuite/pom.xml
file I add the import of 'ee' to its dependencyManagement, making that set
visible to all children. But I use a property for the bom artifactId. This
makes it simple for child modules or a profile to override the property and
change the dependency set. For example, the ts.ee9 profile in
ts/integration/microprofile-tck switches it to wildfly-preview and voila
the TCKs that run are MP 5, not MP 4, and the needed EE 10 deps are used.
Another thing to do in the future would be to move test-only deps out of
the other boms and into their own. We've done a bit of that in WildFly Core.
I'm hoping my just-push current draft PR will pass CI.
Next steps:
a) My PR currently has a 'wildfly-servlet' bom as well that 'ee' depends
on. I'll get rid of that today and move its content into the 'ee' bom.
b) Discussion here or in zulip at [2].
c) File a JIRA, use in commit msgs.
d) Get [1] reviewd and merged.
e) Before 27 Beta decide the names/locations of the boms and get that
implemented. I don't think this needs to block d) though as what's there
now works.
f) Perhaps more cleanup, e.g. the 'common' bom includes some
org.wildfly:wildlfy-xxx[-jakarta] artifacts that differ between std WF and
WFP. OTOH as we move std WF to jakarta.* that difference will go away.
[1] https://github.com/wildfly/wildfly/pull/15575
[2]
https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
Best regards,
Brian Stansberry