Hi Raymond,
Good debate - and I'm not unsympathetic - some comments below.
Yours, Mike.
Raymond Feng wrote:
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.
OK, so this is getting towards the heart of the matter.
Can we be clear about what "runtime dependencies" are the issue here.
Do you have a clearly defined set of dependencies which are acceptable for tooling use, and a set
which are regarded as "runtime" and are unacceptable?
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.
I agree that Module 2 is unusuable without module 3, but module 3 depends on a load of Spring stuff
too. Combining 2 & 3 makes no more sense than combining 3 with Spring itself.
I have no problem with the renaming of module 3.
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.
