[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