[wildfly-dev] Using feature packs for custom distributions

[Tristan Tarrant]

Hi Marko,

I ran into the same issue recently and there is a thread on this mailing 
list about it [1].
I ended up working my way "down" from wildfly-full to infinispan server, 
since it involved less work and less trial and error.
In our case we don't even want any of the servlet and web related stuff 
(i.e. undertow) since our frontend is Netty, but I'd much rather use 
wildfly-web as a base than our current solution (less stuff to remove == 
less things that can go wrong). One potential solution is to "fork" the 
upstream subsystems, even just for tweaking the module.xml (I know it's 
dangerous practice, but it has proven quite effective).

Tristan

[1] http://lists.jboss.org/pipermail/wildfly-dev/2015-May/003984.html

On 09/07/2015 14:57, Marko Strukelj 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
>
>
> 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 ...
>
>
> 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
>

-- 
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat