[wildfly-dev] Re: Updates to how dependency management works in main

I think this makes a lot of sense and definitely makes future previews better too. On Thu, May 26, 2022 at 9:22 AM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > 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 > > _______________________________________________ > 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 -- James R. Perkins JBoss by Red Hat _______________________________________________ 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