The feature-pack build tool is a tool thats intended for creating WildFly distributions
(#1), its not intended to create layered project/products[A] / overlays (#2). For #2, the
solution is really just packaging a subsystem in an extension jar, and thats something
easily achieved with just the standard maven tools.
I can certainly see why you would want to do #1 or #2, but I have a hard time seeing why
you would want to do both.
As to #3, the notion of a runtime provisioning system similar to something like a yum tool
is a long term goal, which I totally agree we need, but its going to be a while before we
can get there (Definitely not 10 nor 11). Alexey has been assembling requirements for it,
and has some ideas around the packaging format. We really want to get it right, so the
plan is to let it grow organically until its proven to be a solid system, and only then
switch to it.
[A]
https://developer.jboss.org/hfurl/redirectToHFURL.jspa?url=/docs/DOC-4792...
On Jul 9, 2015, at 9:02 AM, Marko Strukelj
<mstrukel(a)redhat.com> wrote:
Currently wildfly-server-provisioning-maven-plugin always generates a full Wildfly
distribution. For Keycloak project we have three different cases of provisioning, and it
would be great to be able to cover it with a common wildfly provided tool:
1) full server distribution
2) overlay distribution (unzip into existing OOTB Wildfly distribution - your problem if
you use unsupported Wildfly version)
3) provision into existing Wildfly server detecting version mismatches, and configuring
existing and additional subsystems for Keycloak to run properly.
First one is what’s currently supported, and what we use.
Second one is what we currently hack up by extracting modules directory from (1) - it
would support this use case better if wildfly-server-provisioning-maven-plugin could
generate 'modules only' for example.
The third one requires a CLI installer tool. I’m not aware that currently there is
something for that, and we are loath to develop one from scratch.
Is it realistic to expect 2) and 3) in not so distant future?
- marko
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)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