4:38 a.m.
On 01/07/14 14:26, Stan Silvert wrote:
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.
I really don't see where you are getting this 'must' from, we may have a
requirement of 'we must be able to enable KeyCloak in our platforms' but
where are you getting the 'we must include KeyCloak in the core
distribution' from?
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.
In another discussion just starting I have also raised the question
could the definition of the management interfaces also be moved into a
subsystem.
The management interfaces are required in domain mode to allow a slave
to connection back and the app server instances to connect back but in
standalone mode I do also see them as something that should be optional.
* Allow the extra dependencies.
* Redesign domain-http
From the perspective of security integration that is already the path
we are moving down.
* 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
>>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>>>
>>>>>> _______________________________________________
>>>>>> wildfly-dev mailing list
>>>>>> wildfly-dev(a)lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>>
>>
_______________________________________________
wildfly-dev mailing list
wildfly-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev