[wildfly-dev] Pending core split

[Darran Lofthouse]

+1 In terms of security capabilities I think the core must be developed 
in a way that leaves it ready for security services to be added but that 
those services should be added in the distributions built on top of the 
core.

This thread has really had most of it's traffic in relation to enabling 
KeyCloak but I anticipate we would also have similar discussions when it 
comes to enabling capabilities provided by PicketLink.

WildFly ELytron is being developed to provide SPIs to allow different 
providers to be used IMO choosing which providers to make available is 
something that should happen when the higher level distribution is 
defined - that should also be the point the default out of the box 
policy is defined as again different distributions would have different 
requirements.

Regards,
Darran Lofthouse.


On 03/07/14 14:05, Bob McWhirter wrote:
> I admitted haven’t been paying super-close attention, but as a member of several teams which build stuff upon AS/WildFly, I’d prefer that anything -core makes zero assumptions, and is as close to a nil container as possible.
>
> Then, let me mix in what I need.
>
> If the minimal baseline includes much more than nothing, then the overhead of building upon WildFly has increased.  When you put things into WildFly ‘by default’, you might be satisfying the 80% case, but there will still be 20% that won’t want whatever is jammed into the box and will consider it gratuitous for their needs.
>
> I vote for -core being only MSC/Modules/DeploymentUnitProcessor stuff, and a pert-near empty standalone.xml.
>
> 	-Bob
>
>
> On Jul 3, 2014, at 8:54 AM, Stan Silvert <ssilvert at redhat.com> wrote:
>
>> On 7/3/2014 5:19 AM, Darran Lofthouse 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?
>>
>> We now have three "out of the boxes".  Three distributions.  So what is
>> available by default on these three distros?
>> core-build
>> web-build
>> full-build
>>
>> First, which of these should have dmr over http available by default,
>> out of the box?
>> Second, of those with dmr over http available, which should have
>> keycloak available by default, out of the box?
>>
>> For now, let's make no distinction about what is enabled by default.  We
>> only care about what is available by default.
>>
>>>
>>> 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
>>>>>>> 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
>>>>
>>>> _______________________________________________
>>>> 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
>