Which codebase?, was: Proposed approach for M2

[Jeremy Boynes <jb...@apache.org>]

Oh look, there's an elephant in the sandbox.

On 6/30/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
> 2. Stage the assembly of our M2 runtime.
> I propose that we start a fresh stream for M2 and  build the runtime through
> baby steps, in parallel with the scenario work.

When I tried to make substantial changes to M1, I ran into a bunch of
problems due to the fragility of its code - just look at
AbstractCompositeContext for example (or if you want to hang on to
breakfast, don't). To avoid those it was easier to start a fresh
stream and pull in pieces from M1, refactoring along the way to reduce
the fragility. Jim and then others joined in along the way leading to
what we have now. The thought of starting over yet again is not very
appealing.

Instead, I suggest we go ahead with what was suggested on IRC three
weeks ago and move the code we have now out of the sandbox and into a
branch. Or perhaps, given there has been no development on the trunk
recently (since mid-May), go ahead and just replace trunk itself.

That gives us something to start from making it easier to support the
high-level scenarios that we come up with. We can incrementally
improve on that code based on what we find using and working with it,
starting by taking a look at the suggestions that you made.

--
Jeremy

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

Re: Which codebase?, was: Proposed approach for M2

[Jim Marino <jm...@myromatours.com>]

On Jul 1, 2006, at 1:17 AM, Jeremy Boynes wrote:

> Oh look, there's an elephant in the sandbox.
>
> On 6/30/06, Jean-Sebastien Delfino <js...@apache.org> wrote:
>> 2. Stage the assembly of our M2 runtime.
>> I propose that we start a fresh stream for M2 and  build the  
>> runtime through
>> baby steps, in parallel with the scenario work.
>
> When I tried to make substantial changes to M1, I ran into a bunch of
> problems due to the fragility of its code - just look at
> AbstractCompositeContext for example (or if you want to hang on to
> breakfast, don't). To avoid those it was easier to start a fresh
> stream and pull in pieces from M1, refactoring along the way to reduce
> the fragility. Jim and then others joined in along the way leading to
> what we have now. The thought of starting over yet again is not very
> appealing.
>
Probably not surprisingly I agree, as the thought of starting over is  
not very appealing, especially in a piecemeal fashion. I feel we are  
at serious risk of loosing momentum if we start from scratch,  
particularly since a number of things are already underway using  
core2 (e.g. Spring integration, the deployer, data transformation,  
the Celtix binding, support for conversations, OSGi integration,  
Groovy support).

Also, I'm not clear on how we would merge M1 and core2. When we  
created core2, we pulled in pieces of M1 where appropriate. While  
some things could be brought over (e.g. parts of the invocation  
chain, annotation processing, some of the loaders, autowire, etc.) a  
lot just couldn't. For example, we pretty much re-wrote the scope  
containers and wound up with a much cleaner design.  Starting over  
like this seems to me to be at least two months of work assuming  
people that have contributed to the core in the past and are familiar  
with it are willing to sign up for this. In contrast, I'd like to be  
in a position sometime this month where we are comfortable having a  
modular core release that people can build extensions with.  
Sebastien, perhaps you could outline which parts of M1 would be  
merged with core2 so I can understand this better?

I'd much prefer we do what Jeremy suggested below and improve core2  
directly. In terms of a codebase that others can get up to speed  
with, it seems to me the best way to do this is not by rewriting it  
piecemeal, but by having a lot of extensions and documentation that  
people can refer to and gradually work their way into core. I believe  
the core is no different than other middleware such as Spring,  
Geronimo, JBoss, Hibernate, etc. in that the nature of the problem  
itself is complex and that complexity is proportionally reflected in  
the architecture but not through to the end-user programming model. I  
also believe that this complexity is best dealt with through  
modularity and "layers" people can start with and gradually work into  
the core (assuming they even want to).

> Instead, I suggest we go ahead with what was suggested on IRC three
> weeks ago and move the code we have now out of the sandbox and into a
> branch. Or perhaps, given there has been no development on the trunk
> recently (since mid-May), go ahead and just replace trunk itself.
>
> That gives us something to start from making it easier to support the
> high-level scenarios that we come up with. We can incrementally
> improve on that code based on what we find using and working with it,
> starting by taking a look at the suggestions that you made.

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


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