[keycloak-dev] release? Stan?

[Stian Thorgersen]

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

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
>