[wildfly-dev] Pending core split

[Darran Lofthouse]

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 at jboss.com <mailto:darran.lofthouse at 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 at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>      >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >>>
>      >>> _______________________________________________
>      >>> wildfly-dev mailing list
>      >>> wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>      >>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>      > _______________________________________________
>      > wildfly-dev mailing list
>      > wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>      > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>      >
>     _______________________________________________
>     wildfly-dev mailing list
>     wildfly-dev at lists.jboss.org <mailto:wildfly-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
>