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>
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>:
>>>
>>> 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