<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I&#39;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.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">A concrete example is what I&#39;m calling &#39;subclassing&#39; where feature pack B is taking something from feature pack A and &#39;extending&#39; it in some way. A concrete example:</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><a href="https://github.com/wildfly/wildfly/blob/master/servlet-galleon-pack/src/main/resources/feature_groups/domain-interfaces.xml">https://github.com/wildfly/wildfly/blob/master/servlet-galleon-pack/src/main/resources/feature_groups/domain-interfaces.xml</a><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">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.)</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">I&#39;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 <a href="https://issues.redhat.com/browse/GAL-319" style="font-family:Arial,Helvetica,sans-serif">https://issues.redhat.com/browse/GAL-319</a>.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">A high level view of what I&#39;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&#39;t need the actual pack.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">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.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">It&#39;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.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">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.</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Best regards,</div><div class="gmail_default" style="font-family:trebuchet ms,sans-serif">Brian</div></div>