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.