[wildfly-dev] Using feature packs for custom distributions

[Jason Greene]

> On Jul 9, 2015, at 8:57 AM, Marko Strukelj <mstrukel at redhat.com> wrote:
> 
> 
> For Keycloak we’ve been trying to create a trimmed down distribution of Keycloak server, basing it on servlet-feature-pack rather than full-feature-pack, since we don’t need many of the subsystems. We’ve encountered some issues though that made us step back and stick to using full-feature-pack as a basis for Keycloak server distribution. If we find a way to address these issues in the future we’ll reconsider, but for now we don’t see much sense in basing our Keycloak distribution on servlet-feature-pack.
> 
> There are two big isues for us:
> 
> 1) Big module dependency trees
> 
> Our goal was to reduce the distribution size by reducing the number of subsystems, and modules shipped. We guessed that since we don’t use EJB, JMS, WS - but basically just JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn’t get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually any additional subsystem - in our case we want to use datasources, which are provided by org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That’s a lot just to get datasources support.
> 
> What’s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency tree as adding Datasources support - that’s how intertwined the dependencies currently are.
> 
> Using servlet-feature-pack for distributions that require some additional subsystems from full-feature-set is thus not very effective to significantly reduce custom distribution’s disk footprint.
> 
> There is a tool I wrote as part of my analysis that I used to analyze the size of dependency trees: https://github.com/mstruk/keycloak-moduletool

Yes it sounds like some work needs to be done here to reduce the dependency chain in this area. Pulling in JCA will require transactions, and currently transactions pulls in weld and web services related items. The former is likely due to the new JTA bean support in EE7, but that should be optional for sure.

> 
> 2) Staying in-sync with changes in full-feature-pack
> 
> Creating a custom feature pack that is a subset of full-feature-pack requires copying module.xml files from wildfly/feature-pack source tree into custom feature pack source tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be precise). As Wildfly development moves on, any changes to module.xml files have to be synced into the custom feature pack. That has the potential to be a huge maintenance burden, and a source of errors. One way to address this would be extended syntax somewhere in feature pack definition project to say something like:
> 
> <module id=”org.jboss.as.connector” from=”full-feature-pack” include-dependencies=”true” skip-optional=”true”/>
> 
> And that would replace copying over module directories, and module.xml files. And guarantee that things remain in-sync.
> 
> For our use-case this would also be addressed by wildfly providing a feature-pack definition that’s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support …

I think this is a good idea, to skip optional deps.

> 
> Another thing is provisioning of feature packs, which I address in another email.
> 
> 
> - marko
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat