I can't see how kernel modularization is related to interface based models.
Model is only part of the SPI, SPI also provides a set os services, which
all have well-defined contracts. I am not sure what extra benefits we have
by supporting different data binding mechanisms for the model objects. If I
remember right, we had this discussion a long while ago and we decided to go
with Java based model objects. I have never found a need to mock model
objects in the tests, as the model objects, as I said earlier, don't have
any behaviour. We often mock, service objects that do have behaviour.
If this about modularizing SPI, I would say it is an affort worth
discussing. However, the model changes, I can't see any visible benefit in
doing that. Since we have already had discussion on this during M1 and we
decided to go with Java based POJO model classes, I believe it is water
under bridge and can't see the point in bringing this up again.
Ta
Meeraj
From: Jim Marino <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: [VOTE] Rewrite kernel model to be based on interfaces
Date: Tue, 20 Mar 2007 08:56:40 -0700
On Mar 20, 2007, at 7:23 AM, Jeremy Boynes wrote:
The current model is based on simple POJOs. Sebastien has proposed
rewriting the configuration model to be based on interfaces with separate
implementation and factory classes. This will have a major impact on the
kernel code and all extensions. This vote is not about what is in the
model, it's is about how the model itself is implemented.
[ ] +1 we should do this
[X ] -1 keep things as they are
-1 from me.
This is an alternative implementation of what we have with kernel and not
just a simple "model refactor" or "modularization". Many of the changes
include rolling back directions we decided to take following the issues
encountered with M1. For example, the move away from pure POJOs and the
reintroduction of AssemblyFactory, the renaming of model objects (e.g.
ComponentDefinition to Component) which will clash with the current
runtime extension model, and the way model references are maintained.
It's unclear how these changes will impact the rest of kernel or why they
were necessary. I understand we need to have a model that more accurately
reflects SCA 1.0. We've been doing this incrementally to date. Why can't
they existing model be evolved?
If someone wants to take the model design in a radically new direction,
I'm fine with doing so but I don't think it should be done in trunk at
this point.
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
_________________________________________________________________
Txt a lot? Get Messenger FREE on your mobile.
https://livemessenger.mobile.uk.msn.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
