[wildfly-dev] [wildfly-swarm-internal] Updating WildFly instance with the Provisioning Tool

Thu Oct 5 17:46:04 EDT 2017

Basically a project build doesn't produce the stuff that can be 
provisioned into a runtime environment.

Be it WildFly Swarm, WildFly Modules or a more "alien" runtime, Fedora RPMs.

Carlo

On 10/04/2017 10:12 PM, Alexey Loubyansky wrote:
> In the case of the provisioning tools, we don't generate module.xml 
> files. Modules are provided by the developers/build process. We 
> provide the mechanism to generate packages from the modules and then 
> the feature-pack.
> When a feature-pack is generated, we know which other feature-packs it 
> depends on. Then when we generate a package from a module we process 
> the module dependencies and figure out on which package(s) from which 
> feature-pack(s) the package we generate should depend on.
>
> I am still not sure whether that answers your question since it's 
> formulated in the context of Swarm and I have a trouble translating it 
> into the context of the feature-pack-based provisioning. I am 
> interested in covering your requirements though. So if it makes sense 
> to you let's continue the discussion or schedule a call to clear 
> things out.
>
> On Wed, Oct 4, 2017 at 7:23 PM, Scott Stark <sstark at redhat.com 
> <mailto:sstark at redhat.com>> wrote:
>
>     Correct. Starting from a pom that contains the artifact
>     dependencies, how to translate this into an appropriate module.xml
>     for the output fraction is a trial and error process currently.
>     Does the information exist so that one could go from GAV and/or
>     package names dependencies to the module that provides said
>     dependencies from amongst a set of wildfly feature pack?
>
>     On Tue, Oct 3, 2017 at 8:03 AM, Bob McWhirter <bmcwhirt at redhat.com
>     <mailto:bmcwhirt at redhat.com>> wrote:
>
>         I think the issue (at least as I’ve found it) is that we either:
>
>         a) scrub around in existing feature-packs and modules/
>         directory to determine if there’s a module.xml matching the
>         thing and version we need or
>
>         b) hand-author a module.xml based upon pom.xml, adding a
>         chance to mess things up.
>
>         -Bob
>
>         On Tue, Oct 3, 2017 at 10:37 AM, Alexey Loubyansky
>         <alexey.loubyansky at redhat.com
>         <mailto:alexey.loubyansky at redhat.com>> wrote:
>
>             It's not exactly clear to me what issue you are
>             describing. But I can provide some basic info on how
>             feature-packs are authored for the wildfly releases (core,
>             servlet, full). Perhaps then you could ask a more specific
>             question.
>
>             A feature-pack represents a specific release. So there
>             will be a feature-pack for the core, another one for the
>             servlet distribution and another one for the full one. In
>             feature-packs, modules are organized into packages (which
>             is an atomic unit of content possibly with dependencies on
>             other packages from the same or another feature-pack).
>             When a feature-pack is generated, the packages are
>             generated from the modules. Each module becomes are
>             package in a feature-pack. And module dependencies become
>             package dependencies. Is it any close to the issue you
>             described?
>
>             On Tue, Oct 3, 2017 at 1:51 AM, Scott Stark
>             <sstark at redhat.com <mailto:sstark at redhat.com>> wrote:
>
>                 Interesting.
>
>                 It brings up a discussion point I have been meaning to
>                 raise across the Wildfly and Wildfly-Swarm teams
>                 regarding tools for the step before this assembly step
>                 of feature-packs and fractions into a distributable
>                 archive.
>
>                 The issue I have seen is that when authoring a
>                 feature-pack or fraction, it is difficult to know how
>                 to configure the module dependencies. One is often
>                 starting with GAV dependencies from a spec, and it is
>                 difficult to know how those map onto modules in
>                 existing feature-packs for fractions. Do we have any
>                 tooling in this area to make this task not a trial and
>                 error effort?
>
>
>
>                 On Mon, Oct 2, 2017 at 7:34 AM, Emmanuel Hugonnet
>                 <ehugonne at redhat.com <mailto:ehugonne at redhat.com>> wrote:
>
>                     Hi,
>
>                     For those who can take 7'26 of their time to look
>                     at what we can do with the new provisioning tool
>                     to build and share custom feature packs.
>
>                     https://www.dropbox.com/s/84133sgsjef7pqs/feature_pack.mp4?dl=0
>                     <https://www.dropbox.com/s/84133sgsjef7pqs/feature_pack.mp4?dl=0>
>
>
>
>                     _______________________________________________
>                     wildfly-dev mailing list
>                     wildfly-dev at lists.jboss.org
>                     <mailto:wildfly-dev at lists.jboss.org>
>                     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>                     <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>
>
>
>                 _______________________________________________
>                 wildfly-dev mailing list
>                 wildfly-dev at lists.jboss.org
>                 <mailto:wildfly-dev at lists.jboss.org>
>                 https://lists.jboss.org/mailman/listinfo/wildfly-dev
>                 <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/20171005/03fbedc6/attachment-0001.html 