Working in trunk, was: Objective of the following sandbox - tuscany/sandbox/sebastien/java

[Jean-Sebastien Delfino <js...@apache.org>]

Jean-Sebastien Delfino wrote:
> ant elder wrote:
>> On 3/25/07, Jean-Sebastien Delfino <js...@apache.org> wrote:
>>>
>>> [snip]
>>> Jean-Sebastien Delfino wrote:
>>> >
>>> >> For example, the "variant implementation of the assembly model" 
>>> has a
>>> >> number of changes that coupled with what you describe above will
>>> >> basically require a re-write of kernel.
>>> >
>>> > I have not committed yet this variant implementation of the assembly
>>> > model as I just started to experiment with it yesterday. What I have
>>> > in the sandbox at the moment is a set of interfaces defining an
>>> > assembly model API, and a default implementation of these interfaces.
>>> > The variant implementation that I'm talking about is a prototype of a
>>> > different implementation of (a subset of) the same model interfaces,
>>> > backed by Spring bean definitions. This will help illustrate how 
>>> clean
>>> > interfaces allow for alternate implementations of one or more 
>>> modules,
>>> > and facilitate the integration with a particular runtime environment
>>> > (Spring in this case). I've just spent a few hours on this prototype
>>> > so it's not really baked yet, but I'll commit what I have soon so 
>>> that
>>> > people can take a look if they are interested.
>>> >
>>>
>>> I just committed a few classes in sca/modules/bean and bean-test under
>>> revision r522186 to show what I meant by a variant implementation of 
>>> the
>>> assembly model.
>>
>>
>> It looks to me like this code you've been doing in the sandbox now has
>> enough to illustrate a lot of the concepts that have been suggested 
>> for a
>> more modular kernel. How about we now talk about what you've done and 
>> about
>> how further development of these ideas could happen in trunk? It 
>> sounds like
>> everyone now agrees we need a more modular kernel, is everyone 
>> willing to
>> start doing this in trunk instead of this sandbox?
>>
>>   ...ant
>>
>
> Ant,
>
> Yes, what I have been doing in the sandbox probably has enough to 
> illustrate modularization of how we handle metadata (models etc.) in 
> our runtime.
>
> Like I said in [1] I think some of this work should be done in trunk. 
> I also think that we need a working trunk and as discussed in [2] I'm 
> not advocating for a complete re-write of the kernel, so we may need 
> to find a way to do this modularization work incrementally. Here are 
> some initial ideas to help do this:
>
> - Move some of these modules to trunk and evolve them in trunk, then 
> port pieces of the runtime that want to use them incrementally over 
> time, when people feel ready for it. For example we could start using 
> the model I have been proposing in the WSDL2Java tool, that does not 
> mean that kernel/core has to change right away.
>
> - Move some of these modules in trunk, and adjust some of the model 
> SPI in trunk (made of classes) to implement the model interfaces that 
> I have been proposing, allowing kernel/core to continue to work with 
> these classes until somebody wishes to do the work to port it to the 
> interfaces. I'm not sure how practical it's going to be, but as usual 
> actually writing the code and trying it will help understand the 
> implications of this approach.
>
>
> What's not in my sandbox yet (and which I would like to see prototyped 
> quickly to help have a concrete discussion on it) is a modularization 
> of the execution part of the kernel. For this to happen I think we 
> need to start looking at ways to assemble our SCA runtime kernel 
> without using SCA itself, as this is causing a sort of a chicken and 
> egg problem at the moment, and preventing modularization of the 
> support for Java components in particular since the kernel/core relies 
> on it to assemble itself.
>
> I'm not sure about how to approach this second part of the 
> modularization work. I had indicated in [2] my intention to try first 
> in the sandbox (try to make the support for Java components a separate 
> module), but I'd very happy to work on it in the trunk if our 
> community feels that it's an acceptable approach.
>
> [1] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15725.html
> [2] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg15978.html
>
> Thoughts?
>

I haven't seen any replies to this, so under revision r523577 I copied 
the assembly and policy model modules that I have been working on in my 
sandbox to the trunk. I put the code under tuscany/java/sca/scdl4j, as 
discussed in [3], for people to review or experiment with it. This is an 
addition to the trunk, not breaking any other module. I'm planning to 
continue to work on this in the trunk under tuscany/java/sca/scdl4j.

[3] http://www.mail-archive.com/tuscany-dev@ws.apache.org/msg16122.html

-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org