See my comments below.
Thanks,
Raymond
--------------------------------------------------
From: "Mike Edwards" <[email protected]>
Sent: Thursday, May 07, 2009 2:40 AM
To: <[email protected]>
Subject: Re: [2.x] Porting Spring Modules into 2.x
Raymond,
Some comments here, which relate to a bigger debate that is going on in
relation to Tuscany structure.
Raymond Feng wrote:
Hi,
Let me clarify a bit here:
Module 1 (implementation-spring) contains the Java model and XML
processors for <implementation.spring> element.
Module 2 (implementation-spring-runtime) contains the runtime logic
(implementation provider) that dispatches SCA invocations to components
using implementation.spring
The separation of 1 and 2 is desired so that 1 can be reused by tools or
SCA domain manager without dragging in the runtime code.
This sounds like a good principle, since it might seem that by NOT
separating "model" and "runtime" code, that tools folk would be pulling in
some huge pile of "runtime" code that they don't need.
However, I note that the TOTAL size of the Spring related Tuscany code is
64K + 13K = 77K. The potential saving to tooling guys is actually very
small. As long as the "runtime" Tuscany Spring classes don't bring in the
actual Spring runtime itself unless asked to run an implementation, then
there is actually little benefit to the tools folks in this instance.
The size is not the big concern. What worries me is the dependency. For
example, if we combine module 1
and module 2, extra "runtime" packages have to be added to the
"Import-Package" header for the OSGi
bundle. As a result, the bundle cannot be resolved unless we have the
"runtime" Tuscany bundles in the tooling
environment such as Eclipse.
So in the case of implementation-spring I'm not convinced about this
separation of 1 & 2. In other cases, where the code in 2 is substantial,
I can see the point. I can also see a point where there is the need for
pluggability of 2 in the case of multiple alternative runtimes. But
neither of those apply to implementation-spring.
Meanwhile there are very real costs to having extra modules to keep track
of. So I think in this case, it is better to combine 1 & 2 into a single
module.
I'm looking for packaging consistency for all extensions added to Tuscany.
That's why I proposed to rename
"implementation-spring-runtime" to "implementation-spring-sca" as we always
use the "-runtime" prefix for
modules that contain "runtime" pieces (such as the Provider) of extensions.
IMO, module 2 is tied to module 3 and it really has dependencies on module
3. Using Class.forName() just hides that.
Without module 3, module 2 is useless.
Module 3 (implementation-spring-sca) handles the sca extension to Spring.
It has direct dependencies on Spring jars.
If Spring jars are shipped with Tuscany or a product that embeds Tuscany,
then 3 can be merged with 2.
I'm not so convinced about that, since the files in 3 are very much linked
to the Spring code - and in an OSGi world, coupling between Spring and the
stuff in 2 is undesirable and unnecessary.
There is one use case that drives us to have 3 in a separate module. If
the Spring jars are packaged in a JEE application, we need to have
"implementation-spring-sca" on the classpath of the application. In such
deployment, Spring classes are not visible to the Tuscany modules (such
as implementation-spring-runtime). As a result, module 2 talks to module
3 using reflection APIs.
Thanks,
Raymond
Yours, Mike.
