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

[Brian Stansberry]

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 at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat