That sounds fine to me ...ant
On Thu, May 7, 2009 at 11:41 AM, Ramkumar R <[email protected]> wrote: > 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 >
