----- Original Message -----
From: "Bill Burke" <bburke(a)redhat.com>
To: "Stian Thorgersen" <stian(a)redhat.com>
Cc: keycloak-dev(a)lists.jboss.org
Sent: Tuesday, 2 December, 2014 5:31:12 PM
Subject: Re: [keycloak-dev] release? Stan?
On 12/2/2014 10:53 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Tuesday, 2 December, 2014 4:11:19 PM
>> Subject: Re: [keycloak-dev] release? Stan?
>>
>>
>>
>> On 12/2/2014 9:02 AM, Stian Thorgersen wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "Bill Burke" <bburke(a)redhat.com>
>>>> To: keycloak-dev(a)lists.jboss.org
>>>> Sent: Tuesday, 2 December, 2014 2:38:32 PM
>>>> Subject: Re: [keycloak-dev] release? Stan?
>>>>
>>>>
>>>>
>>>> On 12/2/2014 7:55 AM, Stan Silvert wrote:
>>>>> On 12/2/2014 4:52 AM, Stian Thorgersen wrote:
>>>>>> Should we upgrade to WF 8.2 and also do some changes to the
distro
>>>>>> before
>>>>>> release?
>>>>> I don't see a reason not to go to WF 8.2. If we do that, let me
know
>>>>> so
>>>>> I can run a quick smoke test on the subsystem before we release.
>>>>>>
>>>>>> With regards to distro we should move the adapters and examples
into
>>>>>> separate downloads. Also, we should move the examples into a
separate
>>>>>> github project (keycloak/keycloak-examples). This will make it
easier
>>>>>> for
>>>>>> those that wants to fork the examples separately.
>>>>>>
>>>>>> Also, we should consider a download based on the web-lite
profile. For
>>>>>> non-JavaEE apps, containers (Docker) and those that want to run
a
>>>>>> standalone KC server it would be nice to have a small as
possible
>>>>>> distro.
>>>>> Depending on how the feature pack turns out, we might be able to
offer
>>>>> many flavors of the appliance distro without any additional effort.
We
>>>>> could have:
>>>>> EAP6 + Keycloak
>>>>> AS7 + Keycloak
>>>>> WF8 (web) + Keycloak
>>>>> WF8 (full) + Keycloak
>>>>> WF 9 beta (web) + Keycloak
>>>>> WF 9 beta (full) + Keycloak
>>>>> etc.
>>>>>
>>>>
>>>> IMO, we just need:
>>>> * war-dist
>>>> * appliance-dist
>>>>
>>>> Appliance distribution would have the most stable platform available.
>>>> Since we can't distribute EAP, then it would be the most stable and
>>>> maintained version of Wildfly that allows us to cluster and deploy
>>>> Keycloak.
>>>
>>> Our download at the moment is 160MB and is really aimed at the first-time
>>> JavaEE user (bundled with examples and documentation). Why should we
>>> require someone that just wants to upgrade their server to download all
>>> of
>>> that? There'll also be loads of people that don't need the JavaEE
parts,
>>> a
>>> NodeJS developer or deploying to cloud for example. I think we could
>>> easily have a standalone Keycloak server download that'd be around
30MB.
>>>
>>> IMO we should have:
>>>
>>> * Minimal server (based on WildFly web/core)
>>> * Full server (based on WildFly full)
>>> * Feature pack - to easily install onto other version of WF, EAP, etc.
>>>
>>> Neither of those downloads should include docs or examples. As we don't
>>> really support installing onto Tomcat or Jetty, why have a war-dist?
>>>
>>
>> I disagree. At least one download should have everything: docs,
>> examples, and a distro that can run the examples. Reducing even simple
>> steps for 1st time users is crucial to adoption. How fast a first time
>> user can get "hello world" running is crucial. BTW, That's a
major
>> reason why your suggestion earlier of having examples on Github is not a
>> great idea.
>
> WildFly, PicketLink, Infinispan, etc. all use the same approach for
> quickstarts. They're in GitHub in a separate project, which can easily be
> forked/cloned by users. This is IMO a much better way to get started than
> downloading a zip. Problem is that currently we don't cater for those that
> want to fork/clone the examples as they have to do everything, which would
> at least stop me from doing it. If we put it in a separate project that
> doesn't stop us from releasing a bundle with everything in it. It just
> adds an extra step to the releasing, which could be automated with a
> script.
>
Just because everybody does it doesn't mean it is a good idea. I really
hate that they do that and have run into problems. Let me give more
reasons why it is a bad idea:
* A user may never have used github
Sure, so let's have a download from them as well. In fact you can download a github
repo with a single click.
* There may be an incompatibility with the version developer is
using
vs. the master example branch.
* Requires user to either edit example pom to point to desired project
version or to checkout correct tag.
I agree with versions being a bit of an issue, but that's easily fixed with tags.
Also, I'm fine with having a bundle with everything in it as well for those that want
that. I just want to cater for those that don't as well.
* Keycloak examples are currently active modules in our main git
repo.
They load up as a module in our IDE. Examples are targeted for refactor
events just like any other project.
You can import multiple mvn projects into the same IDE project.
* Keycloak examples are built with build. Thus catching any
compiler
bugs that often happen when refactoring Keycloak SPIs, APIs, or whatever.
See above + we should have continuous integration running tests on examples against head
of KC
> Personally, I download servers then read docs online and clone/fork
> examples/quickstarts. Second time around I don't need examples/quickstarts
> and it annoys me that I have to get a bundle with everything, when all I
> want is the server.
>
The extra few seconds it takes to download and extract really bothers
you that much?
tgz's can be piped into tar to be extracted directly when downloading. It's nice
for scripting things and annoys me when other software isn't available as a tgz.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com