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

[Emmanuel Bernard]

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