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

Yeah this is a key goal of features. You can do something like "feature install org.blah.feature”, and it fetches it from maven and installs it. On Sep 29, 2014, at 11:42 AM, Brian Stansberry <brian.stansberry(a)redhat.com&gt; wrote: -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

Yes: https://developer.jboss.org/wiki/WildflyProvisioning -Bilge ----- Original Message ----- | From: "Emmanuel Bernard" <emmanuel(a)hibernate.org&gt; | To: "Jason Greene" <jason.greene(a)redhat.com&gt; | Cc: wildfly-dev(a)lists.jboss.org | Sent: Thursday, October 9, 2014 7:27:39 AM | Subject: Re: [wildfly-dev] Deliver 3rd party subsystem to customers? | I'm interested in that kind of ability as well. | Is there a wiki describing the what and how I could lurke and contribute | on the use cases side? | Emmanuel | On Mon 2014-09-29 11:56, Jason Greene wrote: | > Yeah this is a key goal of features. | > | > You can do something like "feature install org.blah.feature”, and it | > fetches it from maven and installs it. | > | > On Sep 29, 2014, at 11:42 AM, Brian Stansberry | > <brian.stansberry(a)redhat.com&gt; wrote: | > | > > 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 | > | > -- | > Jason T. Greene | > WildFly Lead / JBoss EAP Platform Architect | > JBoss, a division of Red Hat | > | > | > _______________________________________________ | > 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