I believe, this debate is growing and yet to settle with an agreement. While the debate is still on....
I would like to propose this.... For 1.x lets stick to the model of having 2 modules... implementation-spring and implementation-spring-runtime as what we have currently. As we are expecting any major changes with 1.x after this point of time. For 2.x, we can still keep the debate on and make changes according to the agreement we come up in relation to Tuscany structure. On Thu, May 7, 2009 at 3:10 PM, Mike Edwards < [email protected]> wrote: > 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. > -- Thanks & Regards, Ramkumar Ramalingam
