Pending core split

classic Classic list List threaded Threaded
55 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Pending core split

Stuart Douglas
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

jtgreene
Administrator
The point of the core platform is to evolve the base manageable runtime independent of the traditional application server. This allows for many different frameworks and server runtimes to be based on WildFly. It’s a very real request we have had for a long time.

The core platform has had a goal from the very beginning to have minimal deps, so if you find yourself adding deps, then it either needs an alternative solution, or it doesn’t belong in core.

On Jun 30, 2014, at 4:47 PM, Stan Silvert <[hidden email]> 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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Tomaž Cerar-2
In reply to this post by Stan Silvert
Stan,

what problems do you have?
Last time I was looking into your integration code, you didn't have any deps that didn't exist in core.

--
tomaz


On Mon, Jun 30, 2014 at 11:47 PM, Stan Silvert <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
In reply to this post by jtgreene
On 6/30/2014 6:03 PM, Jason Greene wrote:
> The point of the core platform is to evolve the base manageable runtime independent of the traditional application server. This allows for many different frameworks and server runtimes to be based on WildFly. It’s a very real request we have had for a long time.
>
> The core platform has had a goal from the very beginning to have minimal deps, so if you find yourself adding deps, then it either needs an alternative solution, or it doesn’t belong in core.
I spent most of last week trying out alternatives and teasing out
dependencies.   No joy so far.

What if we moved domain-http into web-build?  That would mean that the
web console would not be available in core-build, but I'm not sure it
makes sense to be there anyway.  Does web console even run against
core-build?

>
> On Jun 30, 2014, at 4:47 PM, Stan Silvert <[hidden email]> 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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> --
> Jason T. Greene
> WildFly Lead / JBoss EAP Platform Architect
> JBoss, a division of Red Hat
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
In reply to this post by Tomaž Cerar-2
On 6/30/2014 6:15 PM, Tomaž Cerar wrote:
Stan,

what problems do you have?
Last time I was looking into your integration code, you didn't have any deps that didn't exist in core.
The Keycloak adapter relies on jackson, RestEasy, iharder, httpcomponents, and undertow-servlet.  I was able to get rid of undertow-servlet, but the others end up pulling in a ton of stuff.

--
tomaz


On Mon, Jun 30, 2014 at 11:47 PM, Stan Silvert <[hidden email]> 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
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
In reply to this post by Stan Silvert
On 6/30/2014 7:27 PM, Stan Silvert wrote:

> On 6/30/2014 6:03 PM, Jason Greene wrote:
>> The point of the core platform is to evolve the base manageable runtime independent of the traditional application server. This allows for many different frameworks and server runtimes to be based on WildFly. It’s a very real request we have had for a long time.
>>
>> The core platform has had a goal from the very beginning to have minimal deps, so if you find yourself adding deps, then it either needs an alternative solution, or it doesn’t belong in core.
> I spent most of last week trying out alternatives and teasing out
> dependencies.   No joy so far.
>
> What if we moved domain-http into web-build?  That would mean that the
> web console would not be available in core-build, but I'm not sure it
> makes sense to be there anyway.  Does web console even run against
> core-build?
Still not sure about web console, but the add-user tool is broken. The
module for it needs to be moved from build to core-build.

>
>> On Jun 30, 2014, at 4:47 PM, Stan Silvert <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stuart Douglas
In reply to this post by Stan Silvert
It really sounds like this should not be part of core, but should be
something extra that just integrates with the core.

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
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
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
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Vaclav Tunka
I thought core is just: MSC, logging, class loading, modules, management

So something fairly generic you can use as a basis for various container
projects. My impression is Keycloak does not belong into the categories
above, but maybe I don't know all the details.

Cheers,
Vaclav

On 07/01/2014 01:55 PM, 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Vaclav Tunka
Enterprise Application Platforms
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Tomaž Cerar-2

On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <[hidden email]> wrote:
My impression is Keycloak does not belong into the categories
above, but maybe I don't know all the details.


You don't have all details, but your reasoning is completely sound.

Idea is to have keycloak auth mechanism as an option to have SSO for admin console.
But that doesn't mean it needs all those dependencies in the core.

We need to distinguish between, auth mechanism that should go to domain-http
and keycloak subsystem which is completely different beast and should go to probably full distro.

--
tomaz

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
On 7/1/2014 8:32 AM, Tomaž Cerar wrote:

On Tue, Jul 1, 2014 at 2:25 PM, Vaclav Tunka <[hidden email]> wrote:
My impression is Keycloak does not belong into the categories
above, but maybe I don't know all the details.


You don't have all details, but your reasoning is completely sound.

Idea is to have keycloak auth mechanism as an option to have SSO for admin console.
But that doesn't mean it needs all those dependencies in the core.

We need to distinguish between, auth mechanism that should go to domain-http
and keycloak subsystem which is completely different beast and should go to probably full distro.
We don't necessarily need the keycloak subsystem in order to use keycloak for authenticating domain-http.  But keycloak subsystem is not the thing that pulls in all the dependencies.  It's the keycloak adapter that does this.

So if we want keycloak to authenticate domain-http out of the box then we have to include all this stuff with it.  That wasn't a problem before the split.  Almost everything it needed was already there.


--
tomaz


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stuart Douglas
In reply to this post by Stan Silvert


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.

This has nothing to do with 'working out of the box', e.g. Servlet and
EJB will 'work out of the box', as long as you pick a distribution that
includes them.




>
>>
>> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
On 7/1/2014 8:49 AM, Stuart Douglas wrote:

>
>
> 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.
>
> This has nothing to do with 'working out of the box', e.g. Servlet and
> EJB will 'work out of the box', as long as you pick a distribution
> that includes them.
I understand.  Perhaps I should have said, 'working out of the box on
core'.  domain-http is currently in core, which is what I'm talking
about here.

>
>
>
>
>>
>>>
>>> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Brian Stansberry
In reply to this post by Stan Silvert
On 6/30/14, 6:27 PM, Stan Silvert wrote:

> On 6/30/2014 6:03 PM, Jason Greene wrote:
>> The point of the core platform is to evolve the base manageable runtime independent of the traditional application server. This allows for many different frameworks and server runtimes to be based on WildFly. It’s a very real request we have had for a long time.
>>
>> The core platform has had a goal from the very beginning to have minimal deps, so if you find yourself adding deps, then it either needs an alternative solution, or it doesn’t belong in core.
> I spent most of last week trying out alternatives and teasing out
> dependencies.   No joy so far.
>
> What if we moved domain-http into web-build?  That would mean that the
> web console would not be available in core-build, but I'm not sure it
> makes sense to be there anyway.  Does web console even run against
> core-build?
>

The http interface is a core capability, even if there is no console.
There are other clients. JON plus whatever custom stuff people have
added over the years.

The console itself is not included in the core. Mostly due to size
considerations -- we want the core to be very light.

What specific issues are you seeing?

>>
>> On Jun 30, 2014, at 4:47 PM, Stan Silvert <[hidden email]> 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
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>> --
>> Jason T. Greene
>> WildFly Lead / JBoss EAP Platform Architect
>> JBoss, a division of Red Hat
>>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Tomaž Cerar-2
In reply to this post by Stan Silvert
i think there could be better way other than using ServletExtension to achieve same thing for what you need in domain-http.
It can stay as is for subsystem stuff.

Also lots of classes in that module, have nothing to do with core SSO need in domain-http (Servlet*)
as there will be no servlet requests coming that way.

In short I think just moving some code around and modifying few classes we could get rid of many dependancies.



On Tue, Jul 1, 2014 at 2:52 PM, Stan Silvert <[hidden email]> wrote:
On 7/1/2014 8:49 AM, Stuart Douglas wrote:
>
>
> 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.
>
> This has nothing to do with 'working out of the box', e.g. Servlet and
> EJB will 'work out of the box', as long as you pick a distribution
> that includes them.
I understand.  Perhaps I should have said, 'working out of the box on
core'.  domain-http is currently in core, which is what I'm talking
about here.
>
>
>
>
>>
>>>
>>> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Brian Stansberry
In reply to this post by Brian Stansberry
On 7/1/14, 7:55 AM, Brian Stansberry wrote:

> On 6/30/14, 6:27 PM, Stan Silvert wrote:
>> On 6/30/2014 6:03 PM, Jason Greene wrote:
>>> The point of the core platform is to evolve the base manageable runtime independent of the traditional application server. This allows for many different frameworks and server runtimes to be based on WildFly. It’s a very real request we have had for a long time.
>>>
>>> The core platform has had a goal from the very beginning to have minimal deps, so if you find yourself adding deps, then it either needs an alternative solution, or it doesn’t belong in core.
>> I spent most of last week trying out alternatives and teasing out
>> dependencies.   No joy so far.
>>
>> What if we moved domain-http into web-build?  That would mean that the
>> web console would not be available in core-build, but I'm not sure it
>> makes sense to be there anyway.  Does web console even run against
>> core-build?
>>
>
> The http interface is a core capability, even if there is no console.
> There are other clients. JON plus whatever custom stuff people have
> added over the years.
>
> The console itself is not included in the core. Mostly due to size
> considerations -- we want the core to be very light.
>
> What specific issues are you seeing?

Never mind this last question -- I replied before getting all my mail
and didn't see the rest of the thread.

>
>>>
>>> On Jun 30, 2014, at 4:47 PM, Stan Silvert <[hidden email]> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> --
>>> Jason T. Greene
>>> WildFly Lead / JBoss EAP Platform Architect
>>> JBoss, a division of Red Hat
>>>
>>
>> _______________________________________________
>> wildfly-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>
>
>


--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stuart Douglas
In reply to this post by Stan Silvert

> I understand. Perhaps I should have said, 'working out of the box on
> core'. domain-http is currently in core, which is what I'm talking about
> here.

I don't follow your logic here. You are basically saying that unless we
can have keycloak in core then there is no point having a core?

Core can't actually do anything out of the box, it is a runtime that
other distributions will build on.

Stuart


>>
>>
>>
>>
>>>
>>>>
>>>> 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
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>
>>>>> _______________________________________________
>>>>> wildfly-dev mailing list
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
In reply to this post by Tomaž Cerar-2
I'm not using KeycloakServletExtension.  I got rid of the dependency on undertow-servlet.

On 7/1/2014 8:58 AM, Tomaž Cerar wrote:
i think there could be better way other than using ServletExtension to achieve same thing for what you need in domain-http.
It can stay as is for subsystem stuff.

Also lots of classes in that module, have nothing to do with core SSO need in domain-http (Servlet*)
as there will be no servlet requests coming that way.

In short I think just moving some code around and modifying few classes we could get rid of many dependancies.



On Tue, Jul 1, 2014 at 2:52 PM, Stan Silvert <[hidden email]> wrote:
On 7/1/2014 8:49 AM, Stuart Douglas wrote:
>
>
> 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.
>
> This has nothing to do with 'working out of the box', e.g. Servlet and
> EJB will 'work out of the box', as long as you pick a distribution
> that includes them.
I understand.  Perhaps I should have said, 'working out of the box on
core'.  domain-http is currently in core, which is what I'm talking
about here.
>
>
>
>
>>
>>>
>>> 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
>>>>> [hidden email]
>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>>> _______________________________________________
>>>> wildfly-dev mailing list
>>>> [hidden email]
>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Pending core split

Stan Silvert
In reply to this post by Stuart Douglas
On 7/1/2014 9:01 AM, Stuart Douglas wrote:
>
>> I understand. Perhaps I should have said, 'working out of the box on
>> core'. domain-http is currently in core, which is what I'm talking about
>> here.
>
> I don't follow your logic here. You are basically saying that unless
> we can have keycloak in core then there is no point having a core?
Of course that's not what I'm saying.  I'm saying that domain-http is
currently in core.  Web console and other clients use domain-http.  If
we want keycloak to authenticate domain-http then keycloak must also be
in core.

There are many possible solutions:
* Don't do the split
* Do the split, but allow core to see the full set of modules.
* Move domain-http out of core.
* Allow the extra dependencies.
* Redesign domain-http
* others?

>
> Core can't actually do anything out of the box, it is a runtime that
> other distributions will build on.
>
> Stuart
>
>
>>>
>>>
>>>
>>>
>>>>
>>>>>
>>>>> 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
>>>>>>> [hidden email]
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> [hidden email]
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
123