Simon, A couple of comments inline...
On 5/28/08, Simon Nash <[EMAIL PROTECTED]> wrote: > Sorry for the long delay in responding. I have been deeply buried > in implementing the new WSDL-less support, and I am only just > surfacing to follow up on other threads. Comments inline. > > Simon > > Rajini Sivaram wrote: > >> On 5/16/08, Simon Nash <[EMAIL PROTECTED]> wrote: >> >>> Jean-Sebastien Delfino wrote: >>> >>> Simon Nash wrote: >>>> ... snip >>>> >>>> I believe that if we are serious about making OSGi-enablement of >>>> Tuscany >>>> >>>>> a >>>>>>> first class option, we should consider doing 1). For the longer term >>>>>>> to >>>>>>> support versioning of 3rd party jars, 1) will provide a standard OSGi >>>>>>> mechanism. As more and more 3rd-party libraries are being >>>>>>> OSGi-enabled, >>>>>>> this >>>>>>> can be seen as an intermediate step which enables users of Tuscany to >>>>>>> install Tuscany in the same standard OSGi way, into an OSGi runtime. >>>>>>> >>>>>>> I agree and think we should do (1) everywhere we can. >>>>>> >>>>>> I don't think Tuscany should modify third-party jars that we >>>>>> >>>>> are redistributing as part of Tuscany. I think we should use >>>>> some variant of (3) for all third-party jars that aren't >>>>> already OSGi-enabled. >>>>> >>>>> >>>>> Can you say why? >>>> >>>> At the moment we are redistributing these libraries as a convenience >>>> >>> for people who want to run Tuscany "out of the box". If people want >>> to obtain these libraries in some other way (e.g., from a maven repo, >>> by direct download from the third-party project, or as part of some >>> other download), that's fine too. >>> >>> This change would alter that picture considerably. For people >>> using Tuscany within OSGi, it would be necessary to use the modified >>> libraries distributed by Tuscany. >>> >> >> >> >> I am not sure if OSGi users of Tuscany would expect 3rd party non-bundle >> jars downloaded from elsewhere to work with Tuscany running under OSGi. If >> there is a requirement, we can support virtual bundles with naive >> manifests >> just for these cases. I am not sure that is reason enough for virtual >> bundles to be the only (or default) option. >> >> On the other hand, I would think that OSGi users of Tuscany may expect 3rd >> party bundle jars from other projects like ServiceMix to work with Tuscany >> running under OSGi. We can easily support that with bundle-ized jars. >> >> It would be great to have some co-ordination between these projects > so that they can share the same bundle-ized 3rd party jars rather > than all creating their own copies and giving the user the problem > of figuring out whose version of bundle-ized jaxb can be used with > Tuscany, ServiceMix, Spring, etc. > > >> This might or might not be required >> >>> outside the OSGi environment, depending on how we set up the distro >>> and the way our extensions locate their third-party dependencies. >>> >> >> >> For users who run Tuscany outside of OSGi, we can (and should) continue to >> support third party libraries downloaded from anywhere. I dont think >> bundle-izing 3rd party libraries will require any changes to the way >> extensions locate their third party dependencies. >> >> If the bundle-izing is only intended for use by the native OSGi Tuscany > runtime, could we produce a separate distro that contains the native > OSGi Tuscany runtime and the bundle-ized 3rd party jars? Our current > binary distro is very large and it would not be good to have it contain > a complete set of unmodified 3rd party jars and another complete set > of the same jars in bundle-ized form. I would also not be keen to > change the regular binary distro to only contain bundle-ized jars > as I think this will be confusing for non-OSGi users of Tuscany, > especially if they don't want to use the exact levels of the 3rd-party > jars that Tuscany has decided to bundle-ize. I looked at ServiceMix4 and I see that it is doing something like >>> this with the org.apache.servicemix.bundles.* files. For example, >>> there's one of these that wraps the JAXB implementation in an OSGi >>> bundle. If we do the same in Tuscany, anyone wanting to use Tuscany >>> with ServiceMix4 in an OSGi environment will need the ServiceMix+JAXB >>> bundle and also the Tuscany+JAXB bundle, duplicating all the JAXB >>> implementation classes. Now add SpringSource and a few other >>> projects into the mix and how many copies of the same JAXB code will >>> the user need? Any number greater than one is the wrong answer. >>> >> >> >> If you install ServiceMix4 and Tuscany, at the moment you will have >> org.apache.servicemix.bundles.jaxb.jar and Tuscany's jaxb.jar on your >> disk. >> Using real bundles, we will replace Tuscany's jaxb.jar with >> org.apache.tuscany.sca.jaxb.jar. We still have two jaxb jars on the >> system. >> Using virtual bundles, we will convert Tuscany's jaxb.jar on the fly to >> org.apache.tuscany.sca.jaxb.jar. The only use case where we reduce disk >> space is where Tuscany's jaxb.jar is shared with other products running >> outside OSGi. >> >> As I said above, I'm not keen to replace jaxb.jar in the Tuscany binary > distro by org.apache.tuscany.sca.jaxb.jar. If this is within the > context of a separate OSGi-specific binary distro, I would be OK > with including bundle-ized jars in that distro. > > But I imagine disk space for jaxb.jar is not the issue. What we want to >> minimize is the number of jaxb bundles installed into an OSGi runtime, >> when >> ServiceMix, Tuscany etc. etc. are installed into one OSGi runtime. There >> is >> nothing stopping Tuscany from using org.apache.servicemix.bundles.jaxb.jar >> or ServiceMix from using org.apache.tuscany.sca.jaxb.jar, if they can >> both use the same version. Both of these (and the SpringSource version) >> have >> the same versioning conventions and export/imports. Using real bundles, we >> enable OSGi users to decide which bundles (and how many of them) they want >> to install into their OSGi runtime. Using virtual bundles, Tuscany will >> probably end up installing jaxb.jar into OSGi regardless of whether there >> are other variants that it can use. We are taking control away from the >> user, and could potentially increase the number of bundles installed >> unnecessarily, and also potentially generate classloading conflicts. >> >> If all the versions of bundle-ized jaxb are the same in terms of > versioning and exports/imports, this can work as you say. Is there > any chance of the OSGi community establishing a maven repo to host > these bundle-ized jars, with a suitable naming convention, so that > they can just be created once rather than n times by every project > that wants to use them? There are many repositories containing bundle-ized jars like SpringSource and http://www.osgi.org/Repository/HomePage. But I am not sure any of this is sufficient for Tuscany, or even whether we want to be tied to a repository like SpringSource. > Another more minor point is that for Graham's minimal OSGi test >> >>> that's going to be part of the main build, it will be necessary to >>> build these "wrapper" bundles, increasing the disk space used by >>> the build because of the need to duplicate the contents of all the >>> third-party jars, which are already in my local maven repo. >>> >> >> >> As far as I know, Graham's minimal OSGi test is a subset of >> itest/osgi-tuscany, and hence relies on a manifest.jar file with >> co-located >> 3rd party jars (it does not load 3rd party jars directly off the maven >> repo). The bundle-ized 3rd party jars will replace these vanilla jars, and >> hence should not have any significant impact on the total disk space used >> by >> the build. >> >> I had expected that the "virtual bundle" approach would be able to > load unmodified jars from the maven repo, combining them with separate > manifests containing the version/export/import information. Is there > some reason why this can't be done? 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 3. OSGi will continue to remain a peripheral feature of Tuscany, never properly integrated since this is not really mainstream. 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. > Simon > > >> Simon >> >>> May you could look at what other projects that have spent time working on >>> >>>> OSGi are doing. Two examples: >>>> - servicemix 4 >>>> - springsource app platform >>>> >>>> There's probably more good examples out there. >>>> >>>> >>> >> >> > -- Thank you... Regards, Rajini
