WFCORE-7439 Port attribute definition implementations from wildfly-clustering-common to wildfly-subsystem

[pferraro]

https://issues.redhat.com/browse/WFCORE-7439 via sub-tasks.

[darranl]

Timing wise this change feels like the kind of thing that is good at the start of a development cycle rather than the end? I don't think this is a priority for WildFly 39 Beta but let me know if there is a need to get this in.

[yersan]

Out of curiosity, why remove the scope of these dependencies if they are expected to be used always in test classloaders? Even if that could be considered as an antipattern for a bom, in this case, the intention of this bom is clear: is for test only dependencies.

I'm assuming that when a dependency incorporated from this test bom declared in a dependency management ssection does not specify the scope, it will get the test scope but, is not that true?

[pferraro]

Out of curiosity, why remove the scope of these dependencies if they are expected to be used always in test classloaders?

• Because that's not how this stuff is meant to work
• This pom defines many artifacts (the one you highlighted is a great example) that are not inherent to test scope.
• The effective pom will otherwise contain artifacts of mixed scopes, since imported artifacts will not have test scope (because, again, that's not how BOMs are supposed to work).

Even if that could be considered as an antipattern for a bom

This isn't actually a BOM. It's an SBOM. A BOM enumerates the artifacts produced by a given build, while an SBOM enumerates the artifacts required to use a given build.

The only scopes that are relevant to the dependencyManagement section of either a BOM or SBOM are: provided and import.
If a module that imports this pom adds a dependency on one the artifacts managed therein, its scope should be predicatable (without requiring help:effective-pom analysis).

[yersan]

Out of curiosity, they are equivalent, aren't they? In such a case, what's the motivation for changing it from type to classifier?

[pferraro]

Because a BOM should only define artifact identifiers, i.e. groupId, artifactId, version, classifier; not packaging types.

[yersan]

There is some related work about this, where we are forcing any attribute definition that loads a module to load the module using the module canonicalized form. See #6584.

Not sure if we can somehow force the Builder for this attribute to always include a ModuleIdentifierUtil.MODULE_NAME_CORRECTOR.

The loader.loadModule(moduleId) accepts an attribute identifier, so my understanding is it should be able to accept both "module:main", "module" or "module:any-slot-name"

[pferraro]

Ah - thanks for pointing this out. At the very least, I should be able to auto-add a custom corrector that delegates to this.

[pferraro]

There is some related work about this, where we are forcing any attribute definition that loads a module to load the module using the module canonicalized form. See #6584.

Is a parameter corrector sufficient for this? AFAICT, the corrector is invoked before the validator, implying that expression are not yet resolved.
What if the resolved expression is not yet in canonicalised form?

[pferraro]

OK - I've added corrector behaviour to the Module and List-based attribute defitions. Let me know if you think there is any additional handling needed.