[keycloak-dev] release? Stan?

Wed Dec 3 11:26:26 EST 2014

Being a KC user and possibly one of those pesky external contributors, I'd
like to throw in a few cents...

1. Github is key to open source developers, but at least 50% of the "Senior
Software Developers" I work with have no clue about it, Linux, tar, or
pipes.  These developers have always worked for companies developing closed
source software, know git only because we have a local git repo and someone
wrote a wiki page on how to use it from IntelliJ, and aren't the ones
selecting 3rd party libraries to use (which are then loaded into our Nexus
repo and magically show up in their builds.)
2. We have a home-grown authentication / authorization system that is
extremely similar to KC.  We used Spring Security OAuth, but almost all
layers of it were replaced by custom implementations to make it hook into
our legacy login system, build tokens with a ton of data in them, and
integrate with SAML.  I think we have close to a million users on our
production system.
3. The main reason I picked KC over using Spring Security OAuth for the
home project I'm working on were the instructional videos Bill did.  More
than any example can possibly do, they helped jump start my understanding
of KC and showed how to integrate it.   After watching those, the examples
turned into a library to copy and paste from.
4. For projects which don't have much documentation (KC is extremely well
documented), cloning an example and playing with it is my preferred way of
getting to know a new library/solution.   To that extent, having the
examples in a separate Git repo (or one repo per platform the exampled
target) does help.

Alain

On Wed, Dec 3, 2014 at 7:28 AM, Stian Thorgersen <stian at redhat.com> 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: Wednesday, 3 December, 2014 3:03:51 PM
> > Subject: Re: [keycloak-dev] release?  Stan?
> >
> >
> >
> > On 12/3/2014 2:38 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 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.
> > >
> >
> > We can barely get contributors to perform a build before submitting a PR.
>
> And you expect external contributors to do large changes to API's or
> refactor code?
>
> With proper CI integration we can build automatically on PRs so
> contributors don't have to run tests at all. Which we should do in either
> case as we can't just merge an external PR without at least checking it
> builds and tests pass first.
>
> >
> > >> * 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
> > >
> >
> > So, more infrastructure to support something that is already done?
>
> There's nothing extra - we don't test examples currently, and testing
> examples whether or not they're part of the core code or a separate project
> makes no difference IMO.
>
> >
> > I just don't see how a git repo for examples gives you any advantages
> > over the current situation.  It just complicates things all around both
> > for users and keycloak contributors.  Seriously what are the advantages
> > other than saving a few meg in a distro?
>
> More and more people are used to GitHub these days, especially in Open
> Source. I certainly wouldn't want to clone a large code-base to get just
> the examples. With a GitHub fork of examples users can fork the examples
> and play with them, instead of having to extract the zip then commit it to
> a separate GitHub. It also lets you add examples or fix examples after a
> release.
>
> For automation/scripting things there's a lot more steps involved, as well
> as a longer spin-up time of images. The more docs (and images) and examples
> we add the bigger the distro. As a user of Keycloak I would actually have
> ended up with repackaging KC server for distribution internally as ours
> isn't suitable for it. This may be a Linux thing, but I have loads of
> scripts that automate things for me.
>
> With the distro I'm looking for I can script installation of KC to just:
>
>   curl <KEYCLOAK DOWNLOAD URL> | tar zx
>
> While with our current distro I need to do:
>
>   curl -O <KEYCLOAK DOWNLOAD URL>
>   unzip keycloak-appliance-dist-all-<KEYCLOAK_VERSION>.zip
>   mv keycloak-appliance-dist-all-<KEYCLOAK_VERSION>/keycloak
> keycloak-<KEYCLOAK_VERSION>
>   rm -rf keycloak-appliance-dist-all-<KEYCLOAK_VERSION>
>
> It would also be nice to have a similar developer experience to other
> JBoss projects.
>
> >
> >
> >
> > --
> > Bill Burke
> > JBoss, a division of Red Hat
> > http://bill.burkecentral.com
> >
> _______________________________________________
> keycloak-dev mailing list
> keycloak-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-dev/attachments/20141203/f10417ba/attachment-0001.html 