----- Original Message -----
From: "Jason Greene" <jason.greene(a)redhat.com>
To: "Marko Strukelj" <mstrukel(a)redhat.com>
Cc: "keycloak dev" <keycloak-dev(a)lists.jboss.org>, "WildFly
Sent: Thursday, 16 July, 2015 12:11:53 AM
Subject: Re: [wildfly-dev] Feature pack provisioning
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
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.
#1 is our standalone Keycloak server distribution - this is the recommended distribution
for production or non-JEE developers
#2 is intended to be used by JEE developers so they can have the KC server bits available
in a single WF instance for development - this is intended as a distribution for JEE
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.
> 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
> 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
> 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
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat
wildfly-dev mailing list