11:21 a.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
1:56 p.m.
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> 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
10:36 a.m.
FYI, we've been discussing the 'component-matrix-builder' module in WF on
zulip[1] and haven't identified a use for it. So I filed a JIRA to remove
it [2] and will send up a (not urgent) PR to remove it. If anyone can think
of a reason to keep it, please speak up.
[1]
https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/to...
[2] https://issues.redhat.com/browse/WFLY-16429
On Thu, May 26, 2022 at 1:56 PM James Perkins <jperkins(a)redhat.com> wrote:
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> 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
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
7:12 a.m.
Hi Brian,
How does these changes affect the WildFly BOMs[1] that are meant for user consumptions (as
opposed to WildFly internal bill of material)?
These boms directly import org.wildfly:wildfly-parent:pom[2] (which brings more than what
a WildFly user actually needs). They will be affected whenever we move WildFly
“user-facing” dependencies outside of its parent.
Have you considered moving these “user” BOMs into WildFly?
In particular, after your changes, it might be simpler to provide such BOMs for the
different feature packs (WildFly Preview in particular).
Best, Regards,
Jeff
[1] https://github.com/wildfly/boms
[2]
https://github.com/wildfly/boms/blob/725e33099ffe8676ad97944d8c54d4a07bdf...
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
8:29 a.m.
Jeff: Only the WildFly BOMs builders need to be updated, to replace the wildfly-parent
import with all the new internal BOMs. The BOMs built do not import anything.
Brian: Can you please list all the artifactIds that provide same set of the old
dependencyManagement, so I update the WildFly BOMs Builders?
—E
On 30 May 2022, at 13:12, Jean-Frederic Mesnil
<jmesnil(a)redhat.com> wrote:
Hi Brian,
How does these changes affect the WildFly BOMs[1] that are meant for user consumptions
(as opposed to WildFly internal bill of material)?
These boms directly import org.wildfly:wildfly-parent:pom[2] (which brings more than what
a WildFly user actually needs). They will be affected whenever we move WildFly
“user-facing” dependencies outside of its parent.
Have you considered moving these “user” BOMs into WildFly?
In particular, after your changes, it might be simpler to provide such BOMs for the
different feature packs (WildFly Preview in particular).
Best, Regards,
Jeff
[1] https://github.com/wildfly/boms
[2]
https://github.com/wildfly/boms/blob/725e33099ffe8676ad97944d8c54d4a07bdf...
--
Jeff Mesnil
Principal Software Engineer
Red Hat
http://jmesnil.net/
10:31 a.m.
On Mon, May 30, 2022 at 8:29 AM Eduardo Martins <emartins(a)redhat.com> wrote:
Jeff: Only the WildFly BOMs builders need to be updated, to replace
the
wildfly-parent import with all the new internal BOMs. The BOMs built do not
import anything.
Brian: Can you please list all the artifactIds that provide same set of
the old dependencyManagement, so I update the WildFly BOMs Builders?
https://github.com/wildfly/wildfly/blob/main/galleon-pack/pom.xml should be
equivalent. I just built the boms replacing wildfly-parent with
wildfly-feature-pack-parent and it built cleanly.
Probably some or most of the boms could use wildfly-ee-feature-pack-parent
instead, but perhaps we should defer making such a change until we decide
whether we want to continue to use the wildfly-[xxx-]feature-pack-parent
pom's I used or instead create separate poms specific to this purpose.
—E
> On 30 May 2022, at 13:12, Jean-Frederic Mesnil <jmesnil(a)redhat.com>
wrote:
>
> Hi Brian,
>
> How does these changes affect the WildFly BOMs[1] that are meant for
user consumptions (as opposed to WildFly internal bill of material)?
>
> These boms directly import org.wildfly:wildfly-parent:pom[2] (which
brings more than what a WildFly user actually needs). They will be affected
whenever we move WildFly “user-facing” dependencies outside of its parent.
>
> Have you considered moving these “user” BOMs into WildFly?
> In particular, after your changes, it might be simpler to provide such
BOMs for the different feature packs (WildFly Preview in particular).
I hadn't considered that, no, but it's a reasonable thing to consider. I
haven't really thought about how that would fit with any longer term
thinking about how we do provisioning, maintenance releases etc.
>
> Best, Regards,
> Jeff
>
>
> [1] https://github.com/wildfly/boms
> [2]
https://github.com/wildfly/boms/blob/725e33099ffe8676ad97944d8c54d4a07bdf...
>
> --
> Jeff Mesnil
> Principal Software Engineer
> Red Hat
> http://jmesnil.net/
>
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
He/Him/His
935
days inactive
940
days old
5 comments
4 participants
participants (4)
-
Brian Stansberry -
Eduardo Martins -
James Perkins -
Jean-Frederic Mesnil