[wildfly-dev] Eliminating 'subclassing' in feature pack config elements

[Brian Stansberry]

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:

https://github.com/wildfly/wildfly/blob/master/servlet-galleon-pack/src/main/resources/feature_groups/domain-interfaces.xml

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20200605/4373a6bb/attachment.html