[keycloak-dev] [wildfly-dev] Feature pack provisioning
stian at redhat.com
Fri Jul 17 04:00:52 EDT 2015
----- Original Message -----
> From: "Jason Greene" <jason.greene at redhat.com>
> To: "Marko Strukelj" <mstrukel at redhat.com>
> Cc: "keycloak dev" <keycloak-dev at lists.jboss.org>, "WildFly Developers" <wildfly-dev at lists.jboss.org>
> 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
> 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.
#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 developers only
> 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 at 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 at 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
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
More information about the keycloak-dev