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?
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>
> 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: http://lists.jboss.org/pipermail/wildfly-dev/2014-September/002919.html
>>> Am 29.09.2014 um 13:36 schrieb "Heiko W.Rupp"
>>> 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
>>> * 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).
>>> wildfly-dev mailing list
>> wildfly-dev mailing list
> Brian Stansberry
> Senior Principal Software Engineer
> JBoss by Red Hat
> wildfly-dev mailing list
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
wildfly-dev mailing list