Agreed. I see feature-packs as the best solution to this kind of thing.
CLI archives are another possibility, with the archive bundling the
module and then the script executes to install it and make needed mods,
but my instinct is the feature-pack stuff will end up being a better
On 9/29/14, 11:30 AM, Heiko Braun wrote:
I think the recently added feature packs work that way. Stuart wrote
about that last week:
> Am 29.09.2014 um 13:36 schrieb "Heiko W.Rupp" <hrupp(a)redhat.com>:
> suppose I am writing a subsystem for WildFly, that I can or want not add to the
generic WildFly codebase (e.g. because it is not open source or because WildFly team would
consider it too special for general consumption).
> Is there a way to package that up in a .zip or any other format (in the good 'ol
days we used .shar files :-)
> to deliver such a subsystem with its module but also the xsl to modify standalone.xml
> If not (yet), would it make sense for WildFly to reconsider allowing to provide e.g.
> * ext.xml
> * subsystem.xml
> * ports.xml
> that will get merged / added to standalone.xml when the module is loaded for the very
> (like when the module.jar is also indexed for the first time).
> wildfly-dev mailing list
wildfly-dev mailing list
Senior Principal Software Engineer
JBoss by Red Hat