Sebastien, Comments inline.
On 10/25/07, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote: > > Some comments and use cases. > > Rajini Sivaram wrote: > > The bundles that I have at the moment are: > > > > 1. org.apache.tuscany.sca.api.jar > > 14,942 bytes > > 2. org.apache.tuscany.sca.tuscany.corespi.jar > > 370,228 bytes > > 3. org.apache.tuscany.sca.tuscany.runtime.jar > > 571,159 bytes > > 4. org.apache.tuscany.sca.tuscany.extensions.jar > 996,238 > > bytes > > 5. org.apache.tuscany.sca.tuscany.dependencies.jar > > 43,928,926 bytes > > > > The dependencies bundle seems pretty big :) > > > >From a packaging point of view, it doesn't make sense to split Tuscany, > > Why doesn't it make sense? (more below about scenarios and requirements) I was talking in relative terms, and purely in terms of the size of the bundles. The whole of Tuscany is only about 2MB, while the 3rd party code is nearly 44MB, so it kind of makes sense to concentrate on splitting the 3rd party code rather than Tuscany. I think the value in splitting Tuscany is more in terms of running multiple versions of Tuscany bundles (under OSGi) rather than reducing the total size of the bundles required in any particular scenario. Unless there are use cases which require only a very small part of the 44MB of 3rd party code, making 900k of extensions look big (your last use case may be one, so I take my statement back). > and > > it makes a lot more sense to split the 3rd party code. > > > > > Did you mean split the 3rd party code from the rest of Tuscany as one > monster 40Mb bundle? or split that monster bundle in a set of smaller > bundles? I would like to split the monster bundle into as many chunks as is manageable. > > I dont want to sound like I am doing a sales pitch for OSGi, but I am > not > > sure there is a cleaner or easier way to sort out versioning issues that > > Tuscany would face if different versions of 3rd party libraries were > > used, compared to running Tuscany under OSGi. An OSGi runtime would > enable > > different versions of 3rd party libraries, different versions of Tuscany > > runtime and different versions of Tuscany extensions to coexist in a > single > > VM with very little extra effort. Implementing something similar with a > > classloader architecture outside of OSGi would be significantly more > complex > > (and will eventually reinvent OSGi). > > > > OK, I like OSGi too :) My previous question about requirements was an > attempt to step back from the technology details and generate some > discussion around the bundle use cases. > > Let me try to help and list the use cases I can think of, and how they > relate to the bundles you've listed. > > - I develop a business application, and I'm using the SCA APIs, I don't > want any dependency on a particular runtime or whatever version of it. > --> happy with oat.sca.api! > > - I developing an extension, using the Tuscany SPI, and running with the > Tuscany runtime > --> happy with oat.corespi > --> would be happy too if oat.core.spi and oat.runtime were a single > bundle as long as the runtime packages are not exported. I guess any > single project that wants to run something is going to have a dependency > on oat.runtime anyway to be able to start the runtime, right? As an extension developer, you should only import packages that are published as SPIs. It shouldn't matter whether the runtime bundle exported packages (for instance to split the runtime itself into multiple bundles). - I'm developing an extension which depends on a 3rd party dependency > from oat.dependencies > --> not happy with a 40Mb bundle > --> what'll happen if I have two copies of Axis2's Axiom in 2 bundles? > can I still pass an axiom element between 2 extensions using these 2 > copies? I guess not... Now I think you are asking for too much. Presumably you have two different versions of Axiom in the two bundles. You can have extensionA(Axiom v1) and extensionB(Axiom v2) coexist as long as they dont want to pass axiom elements between them. And you can have extensionA(Axiom v1) and extension B(Axiom v1) coexist and pass axiom elements between them, and these can coexist which extensionC(Axiom v2) and extensionD(Axiom v2) which pass axiom elements between C and D. > - I just developed version v4.0.3 of implementation-java, which requires > xml-api v47.12, unfortunately incompatible with the xml-api version in > Tuscany v4.0.2. > --> can we walk through the steps to upgrade my bundle-ized Tuscany > v4.0.2 working with my implementation-java v4.0.3? At the moment, I doubt this will be possible (I think you are deliberately trying to make my life difficult). I can give you an alternative scenario that is similar, but is more achievable. If you have developed v4.0.3 of binding-ws-axis2, which requires a new version of Axis2, which is incompatible with the version of Axis2 used in Tuscany v4.0.2, you should be able to upgrade Tuscany 4.0.2 to work with binding-ws-axis2 v4.0.3. I think you will run into problems if you upgraded implementation-java to a new incompatible version of xml-api, since xml-api is also used by SPI and Runtime, and (I may be wrong but ) I imagine there are objects of classes from xml-api which get passed around these bundles. > - I'm an application developer and I'm developing and deploying a Web > application that uses a Java component and a JSONRPC binding > --> not happy with having to package the 900K bundle in my webapp > --> and I'm not even thinking about deploying the 40Mb bundle in it... :) >From the dependency graph that we have today, I think it should be possible to split the extensions into a collection of bundles - not at the current maven module level, but by defining bundles for each of the clusters of extensions which are dependent on each other. Thoughts? It would be good if others could jump-in with the use cases > they have in mind for an bundle-ized Tuscany. The bundle structure that > has been discussed so far seems to go in the right direction, I'm sure > that more use cases will help come up with a useful structure. We would like to use Tuscany bindings to implement distributed-OSGi. Ideally, given any specific binding, we would like to define a minimal set of bundles which should be installed under OSGi to use that binding (with a minimal total size). This does imply splitting both Tuscany extension bundle and the big 3rd party bundle, into smaller chunks. Because of its size, I am more inclined to split the 3rd party bundle into smaller bundles first (though I have no idea where to start with this huge big list of jar files). Once the classloader changes in Tuscany have been implemented, I am hoping that bundle-izing Tuscany will be a packaging exercise which doesn't require any non-OSGi code changes. Thank you very much for the use cases that you provided. They provide a set of very useful requirements that I will use those as the basis to get started. And more use cases will be very helpful. > -- > Jean-Sebastien > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > Thank you... Regards, Rajini
