Simon, A few comments inline...
On 5/29/08, Simon Nash <[EMAIL PROTECTED]> wrote: > Jean-Sebastien Delfino wrote: > >> Rajini Sivaram wrote: >> >> There is no technical reason why we can't store 3rd party jars separately >>> and merge them at runtime to create "virtual bundles", rather than >>> distribute "real bundles" containing these manifests. I think the issues >>> are: >>> >>> 1. The build will be harder and messier since existing tools are not >>> geared to do this >>> 2. The distribution will be messier from an OSGi perspective >>> >> >> Agreed. How about keeping things simple and clean?? >> >> 3. OSGi will continue to remain a peripheral feature of Tuscany, never >>> properly integrated since this is not really mainstream. >>> >> >> Agreed. >> >> 4. Real bundles provide more flexibility to OSGi users in terms of >>> substituting 3rd party jars with newer or patched versions of these, as >>> well >>> as avoiding classloading conflicts resulting from version constraints. >>> >>> >> Good point too. >> >> My 2c: Generating bundles automatically from JARs is useless. If you want >> to leverage OSGi you need to make authoring / fine tuning your >> imports/exports a first class part of your development process. >> >> To clarify what I have been saying, I agree with this and I was > expecting that virtual bundles would be constructed in this way. Even though we can technically generate the exact same manifest entry for virtual bundles as we would for real bundles, IMHO decoupling manifest entries which describe very fine grained information about a bundle like the exact versions of packages it imports from the 3rd party jar and storing it in the Tuscany distribution in a non-standard way is just the wrong thing to do. Like we have already shown with itest/osgi-tuscany, virtual bundles provide a quick and easy way for a large project to get up and running inside an OSGi runtime. But IMO, the virtual bundle approach has WORKAROUND written all over it. > I'm starting to feel like a broken record, so I'm going to say it one last >> time, for the record. I think we should just follow a simple approach and >> add proper (authored) OSGi entries to our JARs and 3rd party dependency >> JARs. This doesn't multiply distros, doesn't duplicate JARs, does not >> complicate the build. It just makes simple sense IMHO, and other projects >> with experience with OSGi are on that path too. >> >> Think of this from a user's perspective. I am downloading Tuscany and > it comes with 149 required dependent bundle-ized 3rd party jars, all at > specific levels chosen by Tuscany, and with Tuscany-specific modifications. I would like to understand what you mean by "Tuscany-specific modifications". IMO interoperating with 3rd party jars bundle-ized outside of Tuscany is not a nice-to-have, it is a must-have. When we bundle-ize a 3rd party jar, all we add are OSGi manifest entries. If we look at the entries that we add these include 1. Bundle symbolic name : 3rd party jars bundle-ized by Tuscany will use the name org.apache.tuscany.sca.xxx. Typically applications will never refer to this name, but in theory they can (eg. to force a bundle to only use imports from a specific bundle). Use of this name will be a deliberate act by an user, and hence we dont introduce any interoperability issues by using a different name. 2. Bundle version and versions of exported packages : Now this is the most crucial information inside a bundle. It is very crucial that we use the same versioning conventions as everyone else. Basically this means that jaxb-impl-2.1.6.jar will use bundle and package version 2.1.6 regardless of whether it was bundle-ized by Tuscany or anyone else. Regardless of whether we use virtual bundles or real bundles, this is an absolute must-have for sharing of classes between applications and Tuscany. 3. Import-Package, Dynamic-ImportPackage and "uses" statements in Export-Package: The actual packages imported are going to based on what is imported, and hence should be identical for a bundle regardless of who bundle-ized it. But there could be (and probably will be) differences in the constraints used in Import-Package and "uses" clauses in exports. These constraints are used to achieve sharing and isolation of classes. For Tuscany, we would probably look at scenarios and tune the constraints for the most common scenarios. But there is always going to be some application somewhere which wishes to use a different set of constraints to achieve a different kind of sharing/isolation. This again comes back to the point that we have to interoperate with bundles generated by other users. And we shouldn't make it too tedious for users to replace Tuscany's copies of 3rd party bundles with their own. IMO, real bundles are much more suited to complex scenarios involving complex versioning/classloading constraints than virtual bundles. > I can't easily apply the Tuscany modfications to other levels of the > same software that I may need to use in place of the levels distributed > by Tuscany. Regardless of whether we use virtual bundles or real bundles, manifest entries from one version of software can't just be used directly on another level of the same software. If using real bundles, the user has to generate a new bundle using a tool like maven-bundle-plugin - there is no Tuscany-specific step here. If using virtual bundles, a new manifest entry has to be created by the user (again using a tool like maven-bundle-plugin) and a matching manifest file and jar has to be fed into Tuscany - the requirement for two matching entities always introduces bigger room for errors, and this is non-standard. I also can't easily share the Tuscany versions of these > bundles with my other software that has the same dependencies at identical > or compatible levels. This is a requirement. It is essential that Tuscany and applications are able to share classes from Tuscany's versions of 3rd party bundles (eg. javax.servlet or jaxb) - otherwise we just wouldn't work. And we definitely dont want to mandate that these applications do anything Tuscany-specific to enable this sharing. Does this make my life easy? I don't think it does. At the very least, real bundles will never make life more complicated than virtual bundles. Simon > > -- Thank you... Regards, Rajini
