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

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(a)redhat.com&gt; 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(a)redhat.com&gt; > 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(a)redhat.com&gt; 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(a)redhat.com&gt; 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(a)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 >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >> >