8:29 a.m.
On 9/16/2014 8:54 AM, Stian Thorgersen wrote:
----- Original Message -----
> From: "Stan Silvert" <ssilvert(a)redhat.com>
> To: "Stian Thorgersen" <stian(a)redhat.com>
> Cc: keycloak-dev(a)lists.jboss.org
> Sent: Tuesday, 16 September, 2014 2:49:46 PM
> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
>
> On 9/16/2014 8:34 AM, Stian Thorgersen wrote:
>> ----- Original Message -----
>>> From: "Stan Silvert" <ssilvert(a)redhat.com>
>>> To: keycloak-dev(a)lists.jboss.org
>>> Sent: Tuesday, 16 September, 2014 2:20:44 PM
>>> Subject: Re: [keycloak-dev] Appliance dist and WildFly feature packs
>>>
>>> On 9/16/2014 5:59 AM, Stian Thorgersen wrote:
>>>> WildFly 9 introduces features packs which seams ideal for us to build
>>>> Keycloak upon.
>>>>
>>>> I'd like to start a "wildfly-9" branch of Keycloak that
uses
>>>> feature-packs
>>>> and WildFly's built in mechanism to create the appliance distro.
This
>>>> would replace our current custom appliance-dist.
>>> I'm already working on this and I've found out that we're just a
little
>>> bit early. See
>>>
http://wildfly-development.1055759.n5.nabble.com/Creating-a-Keycloak-Feat...
>> Great :)
>>
>> Are you providing this directly in Keycloak, or do you have it somewhere
>> else?
> The plan is to have it all live in the Keycloak project. But perhaps we
> should talk about whether or not it makes sense as a Keycloak subproject
> or as just a Maven submodule.
I'd say it should be a Maven submodule as then we can use it to build our
appliance(s)
We can still do that if it is a Keycloak subproject.
The issue is about release schedules. If it is a Keycloak subproject
then the feature pack can have its own releases. This might be
necessary in order to keep up with changes in WildFly and EAP releases.
If it is a subproject then we would probably do a feature pack release
every time we do a Keycloak release. However, let's say WildFly does a
release that breaks our feature pack. We might not be ready to do a
Keycloak release but we could do a feature pack release to fix the problem.
On the other hand, I'm not sure if it's worth the overhead to have the
subproject. Maybe we should start it out as a submodule and move it
later if needed.
> The Keycloak Feature Pack definitely will not live in WildFly. WildFly
> itself is breaking up into more and more subprojects.
>>> We need Stuart to implement a feature to solve issue #2 and I'm working
>>> on issue #3 right now so that we can properly install the auth server in
>>> a domain environment.
>>>> Further I'd like us to have two flavours of Keycloak:
>>>>
>>>> * "appliance-lite": minimum Keycloak server only dist. For
those that
>>>> want
>>>> a standalone Keycloak server. Builds on WildFly "web-lite"
dist, but we
>>>> need to add Hibernate, RestEasy and Connectors (datasources) as well
>>>> * "appliance": full WildFly dist. For those that want to
co-locate their
>>>> JavaEE apps with the Keycloak server. Builds on the full WildFly dist.
>>> We need to think long and hard about this one. Do we really want two
>>> appliance downloads?
>> I think we'll want to at least have a standalone Keycloak server. However,
>> only having that will make it harder for developers and also for anyone
>> that wants to try our examples.
> What are you thinking of that will be harder if we only have one appliance?
If we only provide a standalone Keycloak server dist (built on web-lite) that would mean
that developers would have to either have a separate WildFly running to deploy examples
and their own JavaEE apps
This is where the provisioning tool might come to our
rescue. I think
the way it will play out is that we keep the appliance as a
downloadable, pre-configured, standalone auth server.
If you want to combine an auth server with other services then you use
the provisioning tool to add Keycloak to your favorite flavor of WildFly.
>>> The answer might come when the WildFly provisioning tool is finished.
>>> This is a tool that lets you "roll your own" server. So it's
possible
>>> that we rely on that. One option might be that we let you download
>>> "appliance-lite" and then you use the provisioning tool to add
other
>>> things you might want.
>>>> I've already tried to run Keycloak on WildFly 9.0.0.alpha1 web-lite
and
>>>> it
>>>> works fine. Only thing I had to do was to include RestEasy and Hibernate
>>>> jars in auth-server.war and configure the database directly in
>>>> keycloak-server.json instead of using a datasource.
>>> Right now it won't run on the web profile. I've submitted a patch
to
>>> WildFly, so that should be fixed in the next release.
>> What doesn't work? It seemed to work fine for me.
> I thought my patch didn't make it into the release. I was wrong. False
> alarm.
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>> _______________________________________________
>>> keycloak-dev mailing list
>>> keycloak-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>
>