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(a)redhat.com
<mailto:sstark@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(a)redhat.com
<mailto:bmcwhirt@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(a)redhat.com
<mailto:alexey.loubyansky@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(a)redhat.com <mailto:sstark@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(a)redhat.com <mailto:ehugonne@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(a)lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org
<mailto:wildfly-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev