Re: [wildfly-dev] Deliver 3rd party subsystem to customers?

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 approach. 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: http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002919.html > > > > > > >> Am 29.09.2014 um 13:36 schrieb "Heiko W.Rupp" <hrupp(a)redhat.com&gt;: >> >> Hey, >> >> 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 (or similar)? >> >> 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 first time >> (like when the module.jar is also indexed for the first time). >> >> Thanks >> Heiko >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat _______________________________________________ wildfly-dev mailing list wildfly-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/wildfly-dev