4:52 a.m.
Should have added, I think it is the split that has complicated what by
default means now.
To me the critical point is that the full security services we can
provide need to be included in the final distribution that will be used
which to me does not automatically mean the core distribution.
On 03/07/14 10:45, Darran Lofthouse wrote:
On 03/07/14 10:28, Tomaž Cerar wrote:
> I think that for start we can make it by default enablable in full
> distro.
>
> Once this is done, and extra work is done on trimming down dependencies
> to go as near JDK as possible
> it could be moved to core distro.
>
> Rome was not build in a day, why would KeyCloak integration /
> implementation be done in just one step.
>
> Isn't it better that we start somewhere to get it out to the people to
> test it as soon as possible
> and when it is ready we decide where it is best resting place and how to
> get there.
+1 That has been my thinking when I suggested we follow an approach of
get it enableable by default rather than enabled by default as we reach
the point it is useable.
>
>
>
> On Thu, Jul 3, 2014 at 11:19 AM, Darran Lofthouse
> <darran.lofthouse(a)jboss.com <mailto:darran.lofthouse@jboss.com>> wrote:
>
>
> > The central question is, do we want Keycloak to work out of
> the box?
> > Before this issue was known, everyone answered "yes".
>
> I think here we had reached the point we were answering the
> question "do
> we want it enableable out of the box?" and the answer to that was
> "yes"
>
> What has not been defined since the split started is what "out of the
> box" actually means now, are we talking out of the box for the
> core or
> out of the box for a complete assembled server?
>
> On 01/07/14 12:55, Stan Silvert wrote:
> > On 6/30/2014 10:43 PM, Stuart Douglas wrote:
> >> It really sounds like this should not be part of core, but
> should be
> >> something extra that just integrates with the core.
> > That may be true, but it's not a decision that should depend on
> how many
> > modules must be added.
> >
> > The central question is, do we want Keycloak to work out of the
> box?
> > Before this issue was known, everyone answered "yes".
> >
> > Should we really determine our feature set based on how many
> modules it
> > requires? I don't think we want do that, which is why I'm having
> > doubts about the current approach.
> >
> >>
> >> In all honesty we are highly unlikely to ever have accepted a PR
> that
> >> added all these dependencies to the core in any case, so it is a
> >> problem that would have had to be solved at some point anyway.
> >>
> >> Stuart
> >>
> >> Stan Silvert wrote:
> >>> I'm starting to have doubts about this split.
> >>>
> >>> Right now I'm trying to integrate the Keycloak (client-side)
> adapter
> >>> into build-core so that the web console can use Keycloak for
> >>> authentication. The problem is that there is a huge web of
> dependencies
> >>> that must be moved over from build to build-core.
> >>>
> >>> What exactly is the split trying to solve?
> >>>
> >>> Stan
> >>>
> >>> On 6/27/2014 12:19 PM, Stuart Douglas wrote:
> >>>> Hi all,
> >>>>
> >>>> So I am moderately confident that we will be ready to split
> out Wildfly
> >>>> core into a separate repository early next week (I'm not
> saying that it
> >>>> will definitely happen in this time frame, just that it
> should be
> >>>> possible).
> >>>>
> >>>> Once this is ready to go I think the basic process will be:
> >>>>
> >>>> - Code freeze on Master
> >>>> - Create the core repo, push new rewritten core history
> >>>> - Release core 1.0.0.Beta1
> >>>> - Create PR against core WF repo that deletes everything in
> core, and
> >>>> uses the core 1.0.0.Beta1 release
> >>>> - End of code freeze
> >>>>
> >>>> Stuart
> >>>> _______________________________________________
> >>>> wildfly-dev mailing list
> >>>> wildfly-dev(a)lists.jboss.org
> <mailto:wildfly-dev@lists.jboss.org>
> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >>>
> >>> _______________________________________________
> >>> wildfly-dev mailing list
> >>> wildfly-dev(a)lists.jboss.org
<mailto:wildfly-dev@lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev(a)lists.jboss.org <mailto:wildfly-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>