Rationalize the feature pack content maven modules

The source code used for non-java archive content in our feature packs is a mess. We have a bunch of maven modules that were created for no-longer-relevant historical reasons, and their existence makes understanding how to do development of new subsystems or promotion of existing ones from WildFly Preview to standard WildFly nearly impossible. Even I forget why some of these things exist. The mess also significantly increases the risk of errors, as we have the same files that end up in the same feature pack duplicated in multiple places.

Consolidating content in the feature pack trees

WildFly produces 3 feature packs – wildfly-ee, wildfly and wildfly-preview – and all of the non-java source content for them should be found in 3 branches of the source tree – ee-feature-pack, galleon-pack, and preview. Content that was added for historical reasons in modules in other parts of the source tree should be moved to one of those 3 branches and those other modules should be removed. Specifically this refers to the servlet-feature-pack modules, the elytron-oidc-client/galleon-common module, and the microprofile/galleon-common module.

It is ok for Galleon content to exist in other places temporarily, if the reason for this is knowledge that the ultimate home of the content is in flux. This was the case for a while with elytron-oidc-client/galleon-common, which is why the existence of the module was historically valid. But once the content finds a permanent feature-pack home it should be moved into the relevant part of the source tree.

Organizing content by 'shareability'

There are two types of content that can appear in the source tree for one of the 3 feature packs. Each feature pack source tree should have a maven module for one or both of these types:

1) Sharable content. This is content that can be shared from standard WildFly to WildFly Preview. This kind of content can only appear in the ee-feature-pack and galleon-pack source trees, as this is standard WildFly content the WFP also wants to consume. The opposite case does not exists.

Both ee-feature-pack and galleon-pack should have a single child module named 'galleon-shared' in which all such content is located. Existing content to move into these modules can be found in existing modules with names like 'common', 'galleon-common', 'pruned' and 'galleon-pruned'. Content in these modules should be reviewed to ensure it's really meant to be shared with WFP. There may also be relevant content in 'galleon-content' modules. However the content in 'galleon-content' modules is much more likely to not be intended for sharing.

2) Non-sharable content. This is standard WildFly content that should not end up in the wildfly-preview feature pack, as well as content that is specific to the wildfly-preview feature pack. The ee-feature-pack, galleon-pack and preview modules should each have a single child module named 'galleon-local' in which all such content is located. The 'preview' tree currently has four modules that should be consolidated into one. For the wildfly-ee and wildfly feature pack trees there may be non-sharable content in various existing modules, but it is most likely to be found in modules named 'galleon-content'.

A longer term goal should be to minimize the amount of non-sharable content in the ee-feature-pack and galleon-pack trees, but that isn't the goal of this JIRA. This JIRA can help with that goal though by making it easier to reason about whether or not particular content is shareable.

Removing duplication

As noted above, there are a number of cases where content with the same file name is present in multiple maven modules that end up as part of the build of a single feature pack. The work related to this JIRA will necessarily remove this duplication by moving to a much smaller number of maven modules. A critical part of this work is ensuring that the correct content file survives this 'de-duplication'. This requires understanding the pom of the feature-pack modules themselves, which use multiple executions of the maven-resource-plugin to copy content from the various source modules into the feature-pack module's own target dir. The copied content is then used to build the feature pack. These maven-resource-plugin executions are down with the 'overwrite' setting set to 'true' so the effect is for any file that appears in multiple places, the last execution in the feature-pack pom file wins. So that is the file that should be preserved.

However, even though we know from the above which file should be preserved, this de-duplication effort is a good opportunity to review any differences that may exist between duplicated files to see if there's something to retain from one of the files being removed. The basic assumption should be that there isn't, particularly for cases where the difference dates back to older releases of WildFly. Differences only introduced during WF 28 development should be reviewed carefully.

Work Plan

Note that this is likely to be accomplished in at least two parts:

1) Part 1 to deal with elytron-oidc-client and servlet-feature-pack.
2) Part(s) > 1 to deal with the rest.

The reason for the split is for WildFly 28 there are a number of higher priority pieces of work going on related to moving Galleon content around, and the Part(s) > 1 work is likely to conflict with that work.