[WFCORE-6755] Move the org.wildfly.security:wildfly-elytron-dynamic-ssl artifact into its own module

[yersan]

Supersedes #5947

Jira issue: https://issues.redhat.com/browse/WFCORE-6755

See https://wildfly.zulipchat.com/#narrow/stream/174184-wildfly-developers/topic/Layers.20and.20optional.20packages.

This PR includes #5947 but removes the community stability property configuration from org.wildfly.security.elytron-dynamic-ssl JBoss Modules module and adds its package as required for the Elytron layer. Until getting a better approach for this case, this will fix the issue reported by the test case where this module was not provisioned when using Elytron Galleon Layer and ensure we can use default stability level out of the box when the server is built targetting this stability level.

[wildfly-ci]

Core -> Full Integration Build 13655 outcome was FAILURE using a merge of 1fc8829
Summary: Tests passed: 169, ignored: 4; exit code 1 (Step: Test full with JDK 11 (Maven)) (new) Build time: 00:17:42

[yersan]

Hello @fjuma / @darranl , a friendly reminder that I requested any of you to review this one, thanks!

[yersan]

@fjuma / @darranl, sorry for the noise, forget my last comment, I have to review the current status first since I lost track of this one, I'm going to remove you from the review until this one gets refreshed

[darranl]

@yersan FYI I will be working on a PR to promote this to default soon, although would be good to know we could solve this situation if it comes up again so I think still worth proceeding for now.

[darranl]

@yersan are we proceeding with this one?

[yersan]

@darranl I want to back to this once we have passed the feature freeze, I plan to take a closer look next week

[yersan]

@darranl kicked it off again, I've added valid-for-stability to the package dependency for Elytron layer, does mean, the package will not be provisioned for an stability level with higher stability than "community"

[yersan]

@darranl do you want to take a look? I am fine with merging this as it is

[yersan]

@darranl friendly reminder, when you have a chance, take a look at this one and approve from your side, thanks!

[darranl]

@yersan we may need to wait on a full solution, at this stage this module must not be provisioned at lower stability levels.

[yersan]

we may need to wait on a full solution, at this stage this module must not be provisioned at lower stability levels.

@darranl the valid-for-stability to the package dependency on Elytron layer does that

[yersan]

we may need to wait on a full solution, at this stage this module must not be provisioned at lower stability levels.

Also, "lower stability", I assume you are talking about higher stability levels (e.g default)

[darranl]

Sorry yes "higher"

[yersan]

@darranl ok, and then, since we are using valid-for-stability, would you agree to resolve this as it is now?

[darranl]

@yersan What we need is a generic solution so that the module is correctly provisioned at the various stability levels and not provisioned when we only support default - do we have that today?

[yersan]

@darranl yes, we are using the "valid-for-stability" attribute at a package level to decide when we want this packaged provisioned, so we are not provisioning it for any stability level higher than community. At conversion time branches we can add a simple maven verify configuration to verify this module is not provisioned so we be more confident about this. I can add that after merging this and rebasing the conversion.

[darranl]

@yersan so both commits on this PR complete that?

[yersan]

@darranl

so both commits on this PR complete that?

One commit picked up the work done by @Skyllarr (this Supersedes #5947) which separates the Elytron dynamic SSL package from Elytron in a separate JBoss Modules module and Galleon package. We had issues with that change because we were not able at that time to provision the separated package/module only in the required stability levels (community and below, even using JBoss Modules <property name="jboss.stability" value="community"/> property name)

The second commit I added to that PR does it. We are now using the valid-for-stability configuration at package level.

If we want to be more confident with these changes, we can use the maven verify plugin and assert this package is not provisioned when we are building to "default" stability level using the conversion branches. This change is not in this PR it is a proposed change to be included via conversion branches.