Simon, Thank you, I will start a new thread on versioning third party bundles in Tuscany. I will copy over the questions from your note to make sure that they are addressed. I will try and put together some examples to illustrate the points from this thread to get started off. Your input and the input of others who understand how Tuscany is really used will be extremely valuable in getting this right (it may just be that I am making it more complicated that it needs to be). I will try to get an initial note out on the mailing list by the end of the week.
Thank you... Regards, Rajini On 6/3/08, Simon Nash <[EMAIL PROTECTED]> wrote: > > See comments inline. > > Simon > > Rajini Sivaram wrote: > >> 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 understand this point and I agree that there is value in adopting > an approach that provides the best experience for OSGi users, as long > as this does not create issues in a non-OSGi environment. > > >> >> 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. >> >> Please can you help me understand point 3 better, preferably with a > simple example of constraints that would be used in a bundle created > by Tuscany and what changes a user might want to make to these for > their own purposes. At the moment I don't understand why it isn't > possible to create a bundle that could be used for all purposes. > > >> >> 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. >> >> I'm concerned by the assumption here that Tuscany's versions of > 3rd party bundles will be used both by Tuscany and by applications. > An application may be using other software as well as Tuscany, and > this other software may include its own versions of bundles for > javax.servlet or jaxb. If Tuscany requires its versions of these > bundles to be used, and the other software requires its versions > to be used, this requires the application developer to understand > how to resolve any conflicts. > > 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. >> >> From the discussions that have taken place on this thread, I accept > that this is the case. Therefore I would like to focus the ongoing > discussion on how we make real bundles work better for OSGi users > who are integrating multiple software packages (see my comments above) > rather than continuing to debate the pros and cons of virtual bundles. > > Simon > >
