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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
