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

[Bilgehan Ozpeynirci]

Yes: 
https://developer.jboss.org/wiki/WildflyProvisioning 

-Bilge 

----- Original Message -----

| From: "Emmanuel Bernard" <emmanuel at hibernate.org>
| To: "Jason Greene" <jason.greene at redhat.com>
| Cc: wildfly-dev at 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 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
| _______________________________________________
| wildfly-dev mailing list
| wildfly-dev at lists.jboss.org
| https://lists.jboss.org/mailman/listinfo/wildfly-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20141009/cf9fede9/attachment.html