[wildfly-dev] Pending core split

[David M. Lloyd]

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.
>>
>

-- 
- DML