[keycloak-dev] release? Stan?

Bill Burke bburke at redhat.com
Tue Dec 2 11:31:12 EST 2014



On 12/2/2014 10:53 AM, Stian Thorgersen wrote:
>
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke at redhat.com>
>> To: "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-dev at 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 at redhat.com>
>>>> To: keycloak-dev at 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
* 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.
* 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.
* Keycloak examples are built with build.  Thus catching any compiler 
bugs that often happen when refactoring Keycloak SPIs, APIs, or whatever.

> 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?


-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com


More information about the keycloak-dev mailing list