Hi Brian, please see inline.
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 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.