9:13 a.m.
On Thu, Aug 7, 2025 at 4:53 PM Eduardo Martins <emartins(a)redhat.com> wrote:
Hi Brian, please see inline.
On 7 Aug 2025, at 19:59, Brian Stansberry via wildfly-dev <
wildfly-dev(a)lists.jboss.org> wrote:
Some thoughts related to our 'bom builder' modules, sparked by the fact
they are causing issues with syncing WildFly content from JBoss Nexus to
Maven Central.
1) The configuration of the plugin that generates the bom includes
elements like 'parent' and 'license' that also appear in the root level
of
a pom. This has led to trouble, so I suggest renaming these elements.
https://issues.redhat.com/browse/NEXUS-967 was a problem where some
tooling on JBoss Nexus was confused by these and was unwilling to sync
content to Central because of the presence of these artifacts. This is now
fixed.
But, now we see Central is rejecting these poms. Exactly why is still
unclear but a theory is that they are looking at the plugin configuration
section, confusing them for document roots, and rejecting the pom because
the 'document root' is missing required elements.
I'll probably file an issue to rename these config elements.
Only had a brief look at the JIRA, will go deeper tomorrow, but looks like
it’s a validation task issue, not the plugin... If that’s the case by
changing the plugin we may be simply delaying the issue to next plugin.
NEXUS-967 is fixed. TBH it was kind of off-topic except as an example of
how pom validating code got confused by these poms.
The critical problem is something being done at Maven Central, using
unknown validation software, not the stuff that was related to NEXUS-967.
We don't have full details on what that is, and I don't know if/when we'd
get them. Maven Central rejects the poms that use
wildfly-bom-builder-plugin and wildfly-component-matrix plugin, saying they
are missing various required stuff like scm element, developers element,
license element etc. These poms all have these things, typically inherited
from ancestors. Same as all the other poms that are not rejected. (Another
theory is the central check gets confused by the deep inheritance tree with
the bom/user poms, but the same happens with core's
component-matrix-builder module, which is a direct child of
wildfly-core-parent.)
I admit, tweaking the plugin config to avoid that is just a guess. Kind of
a backup plan in case we can't get whatever the issue is sorted at Sonatype.
2) Full WF uses `wildfly-bom-builder-plugin` for bom generation,
while
core has a 'component-matrix-builder' module that uses a
`wildfly-component-matrix-plugin`. These look very similar. Can't we just
use `wildfly-bom-builder-plugin` in core? Both plugins have a similar
config that has the issues discussed in #1.
The bom builder plugin was based on the component matrix plugin, thus the
config similarities, but IIRC both plugins are quite different at this
point.
I checked and they produce the same results for the one use of
component-matrix-plugin, so, if we keep that one use we should use the
plugin that's being updated.
3) AFAICT output of Core's component-matrix-builder module
isn't used
anywhere, nor do we do anything to maintain it. One substantive commit
since 2019. We should either:
a) Drop this, or
b) Use it in WF as the 'core-bom' instead of using wildfly-core-parent.
I filed https://issues.redhat.com/browse/WFLY-20833 to explore the latter
idea.
I think the component matrix is no longer used anywhere, even downstream,
the internal non user BOMs you introduced at some point are the natural
successors, so IMHO let’s drop it.
Are other things using wildfly-core-parent as a bom? I'm thinking of
management clients (Galleon stuff, WF ARQ etc.)
But even if they are, wildfly-component-matrix isn't the right thing to use
either. A proper WildFly Core client bom would be more appropriate.
—E
--
Brian Stansberry
Architect, JBoss EAP
WildFly Project Lead
He/Him/His