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.
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.
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.
