On Jun 23, 2014, at 2:52 PM, David M. Lloyd <david.lloyd(a)redhat.com> wrote:
On 06/23/2014 01:20 PM, Brian Stansberry wrote:
> As we continue with our work splitting the WildFly code base into a core
> repo and then separate repos related to sets of features that we need to
> solidify the contracts between the various features and between features
> and the core.
>
> I've taken a crack at an initial design document on this: see [1]. We
> also need to do the practical work of identifying the various
> dependencies between our existing subsystems, see [2] for a start on that.
>
> I'd love to get feedback on this thread regarding the proposed design,
> as well as get direct edits on the [2] doc to flesh out the existing
> relationships.
Here is what jumps out at me at first.
• I don't understand the reason to not allow optional dependencies on
capabilities. It would be of similar implementation complexity to the
suggested permutation implementation, however it would avoid the problem
of requiring 2ⁿ permutations for n optional dependencies.
I had the same thought.
• I don't understand the purpose of binding capability identifiers to
subsystem identifiers. It seems plausible to have a subsystem provide,
for example, two capabilities now, but allow for a capability to be
implemented separately in the future. A concrete example would be the
way we ultimately moved Servlet from JBoss Web to Undertow. Ideally
we'd only ever depend on the capability, making subsystems completely
interchangeable.
I think Brian was trying to allow for thirdparty subsystems to potentially collaborate
without a global registration (like we have with Phases). In practice I would imagine all
of our out of the box subsystems would be using null. Alternatively we could just use some
kind of ad-hoc string as a group name or something.
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat