I've been thinking some about how we can improve our flexibility in producing different flavors of WildFly and one area that may help and hopefully would be pretty simple is reducing / eliminating hard references from one feature pack to another in the various configuration content that ends up in the FP.

A concrete example is what I'm calling 'subclassing' where feature pack B is taking something from feature pack A and 'extending' it in some way. A concrete example:

It would be nice to get rid of that kind of thing. (There may be better examples; that was just the first one I noticed when randomly poking.)

I'm bringing this up somewhat to socialize the general topic of looser coupling between codebases when producing feature packs, something I also get into with https://issues.redhat.com/browse/GAL-319.

A high level view of what I'm thinking about is if I want to produce a wildfly-ee feature pack, why does it need to depend on a wildfly-core feature pack?  It needs some configuration and package content from WildFly Core, and it needs a dependency set (which it could override if wanted.) But it shouldn't need the actual pack.

This is helpful when producing software, as it reduces the requirement to do new releases. For example yesterday we could have dispensed with a WildFly Core 12.0.1 release needed for WF 20 just to bring in a couple component upgrades. WildFly could have simply overridden the component versions.

It's also helpful for UX and general API control. If a wildfly-ee FP depends on wildfly-servlet and wildfly-core FPs, then those FPs become visible to end users, which is more complex and reduces the ability to evolve things in the future.

As we work on things like doing an EE 9 variant of WF using a hierarchy of feature packs is going to get significantly more so I think we need to get beyond that.

Best regards,

Brian