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.