[wildfly-dev] Pending core split

[Thomas Heute]

I think it just needed clarifications.

On 07/03/2014 04:29 PM, David M. Lloyd wrote:
> Now that we've democratically wasted everyone's time fairly on this, can
> we please all get back to work?
>
> Note that all this dickering has not actually changed the course in any
> measurable way - a sure sign of wasted effort.
>
> On 07/03/2014 09:26 AM, Thomas Heute wrote:
>> We just had a quick call, here is the summary:
>>
>> Tomaz Cerar
>> Stan Silvert
>> Darran Lofthouse
>> Thomas Heute
>> Stian Thorgersen
>>
>> WF "distributions":
>>       WF Core = bare minimum (CLI included, DMR over HTTP, no console),
>> CLI/DMR over HTTP would be secured the way it is already (ie: without KC)
>>       WF Web = WF Core + Servlet Container (Tomcat alternative)
>>       WF Full = What we have today
>>
>> Future:
>>       Support for extensions on host controller
>>       Elytron
>>
>> Plan:
>>       Keep KC integration pluggable and added in WF Full first (could go
>> down to WF Web or whatever other profiles but after).
>>           Domain HTTP module needs an "optional" dependency on KC
>>       No need to wait on Elytron
>>
>> Additional link/info:
>> https://community.jboss.org/wiki/WildFly9-HTTPManagementInterfaceConfiguration
>>
>> Thomas
>>
>>
>>
>> On 07/03/2014 04:11 PM, David M. Lloyd wrote:
>>> On 07/03/2014 09:02 AM, Stan Silvert wrote:
>>>> On 7/3/2014 9:21 AM, Stuart Douglas wrote:
>>>>>
>>>>> 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.
>>>>>>
>>>>> That is the intention.
>>>>>
>>>>> You also need to keep in mind that you can't actually do anything with
>>>>> core without first installing some extensions. Nothing works out of
>>>>> the box on core, because there is nothing there to do any work.
>>>> Nothing works out of the box on core?
>>>> Does this mean web console doesn't work?
>>>> Does this mean CLI doesn't work?
>>>>
>>>> I think it's perfectly acceptable to choose yes or no to any of these,
>>>> but we need to answer those questions to move forward.
>>> In point of fact, no we don't.  In order to move forward, we need to
>>> terminate this pointless email thread.  The core split is necessarily
>>> going to be incremental and iterative - we are still quite a ways away
>>> from being able to apply this kind of broad principle, and anyway it has
>>> zero bearing on what you need to be doing, AFAICT.
>>>
>>> Splitting up a monolithic codebase as big and complex as WildFly isn't
>>> something that can or should be armchair quarterbacked.  Either help
>>> directly in a pragmatic and incremental manner, or just let it happen as
>>> it needs to happen; competent hands are on the helm.
>>>
>>
>