The existing modules under core-feature-pack are a leftover from past organizational requirements.

common
ee-10-api
galleon-common
galleon-feature-pack

1) The galleon-common content should move into the same place as the 'common' content. The distinction between 'common' and 'galleon-common' is a leftover from when we had the pre-galleon feature pack system.

2) We should decide what we call that 'same place'. A common practice is we use 'galleon-shared' for stuff that can be used in different FPs, and then 'galleon-local' for stuff that is only relevant for the FP built in the same source tree (i.e. the wildfly-core FP built in the core-feature-pack/galleon-feature-pack module.). Following that pattern, this 'same place' would be called 'galleon-shared'. This content ends up shared between the wildfly-core, wildfly-ee and wildfly-preview feature packs. (There is no galleon-local here.)

Note that if we move stuff out of 'common' we'll need to do a multi-step dance; i.e. create the new, but empty thing, integrate it into the FP builds in full WF, then move the content to the new thing, then remove the old thing from from the FP builds in WF, and finally remove the old thing.

3) I think ee-10-api is ok even though we long ago got rid of the equivalent in full WF. As soon as we'd remove it we'd decide we want an ee-11-api vs ee-10-api distinction, so let's leave it.

Given the complexity of #2, perhaps the thing to do is start with a subtask to move the galleon-common content to 'common' and worry about the rest later.

BTW, the comment by jdenise@redhat.com at https://github.com/wildfly/wildfly/pull/18149#discussion_r1732844772 is what sparked this. The separation of content between galleon-common and common is a source of fragility.