[wildfly-dev] Pending core split

[Jason Greene]

The only thing on the list that can be done with the libraries already provided in Core (and the JDK itself) is bouncy castle, which might very well get added eventually.

If you go back and read the proposals though, the eventual plan is to make WildFly extensions remotely downloadable. So if you want KeyCloak integration you will be able to run a prov tool to download and install it. The plan is also to be able to create your own dist from an XML file assembled by that tool (or by editing). So in a nutshell it will be very easy for thirdparty distributions to pull in a keycloak-adapter extension, should that be the direction. No matter we can definitely include this in the primary WildFly distro.

Anyway the choose is basically live with a very limited set of deps, or target one of the higher layers.

Note that everyone can make an argument that core should include their favorite small set of libs. The aggregate of everyone doing that is a full distribution.


On Jul 1, 2014, at 8:39 AM, Tomaž Cerar <tomaz.cerar at gmail.com> wrote:

> "Stuff", that Bill said, sounds ok to be part of core.
> At least in its most bare versions (as all 3 libs can have many modules)
> 
> 
> RestEasy should never get pulled in, as it requires servlets again...
> 
> 
> On Tue, Jul 1, 2014 at 3:36 PM, Stan Silvert <ssilvert at redhat.com> wrote:
> On 7/1/2014 9:33 AM, Bill Burke wrote:
> >
> > On 7/1/2014 8:48 AM, Stan Silvert wrote:
> >> On 7/1/2014 8:32 AM, Tomaž Cerar wrote:
> >>> On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <vtunka at redhat.com
> >>> <mailto:vtunka at redhat.com>> wrote:
> >>>
> >>>      My impression is Keycloak does not belong into the categories
> >>>      above, but maybe I don't know all the details.
> >>>
> >>>
> >>>
> >>> You don't have all details, but your reasoning is completely sound.
> >>>
> >>> Idea is to have keycloak auth mechanism as an option to have SSO for
> >>> admin console.
> >>> But that doesn't mean it needs all those dependencies in the core.
> >>>
> >>> We need to distinguish between, auth mechanism that should go to
> >>> domain-http
> >>> and keycloak subsystem which is completely different beast and should
> >>> go to probably full distro.
> >> We don't necessarily need the keycloak subsystem in order to use
> >> keycloak for authenticating domain-http.  But keycloak subsystem is not
> >> the thing that pulls in all the dependencies.  It's the keycloak adapter
> >> that does this.
> >>
> >> So if we want keycloak to authenticate domain-http out of the box then
> >> we have to include all this stuff with it.  That wasn't a problem before
> >> the split.  Almost everything it needed was already there.
> >>
> > "All this stuff" is really just Apache Http Client, Jackson and
> > Bouncycastle.
> >
> >
> Resteasy got pulled in as well.  Maybe that was an error on my part?
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> 
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat