Well, unfortunately this is kinda true. I think the spec is great in terms of capabilities, but first of all everyone needs to understand the implications of version number schemes. OSGi is great to gain quick benefits, but if it is adapted in a very simple way (only plain exports without version numbers, imports without version ranges and so on) the benefits are very limited. Actually, I even think it might cause sooner or later real problems with interoperability. More in the terms of awareness and training should be done. Otherwise we might end up with thousands of bundles not worth a thing, because we can't rely on them. Everything has to be done by hand. The ultimate goal should be to have tooling support to automatically generate these numbers. The tool should detect version changes between releases on a semantic and syntactic level and change the version numbers accordingly. No human interaction should be required. This is the way to go I think. The only thing the bundle developer should be involved with is defining the version to export - even imports with version ranges should be handled by the tool. This would leverage software reuse and put modularization on a completely new level! Well, although this is not impossible, it is far from reality right now and it is certainly not part of a specification. It would be interesting if someone is already working on something like this. I know Eclipse 3.4 is trying to do things like that, but till now I couldn't find any documentation on that. If some knows anything, I would be interested to know about it!
Cheers, Mirko On Wed, Jun 4, 2008 at 5:24 PM, Alan Cabrera <[EMAIL PROTECTED]> wrote: > > On Jun 4, 2008, at 1:21 AM, Rajini Sivaram wrote: > >> >> Thank you all for the replies with all the useful information and >> pointers. >> >> For versioning Tuscany bundles themselves, we are using >> maven-bundle-plugin at the moment, which gives us import and "uses" clauses >> with version="2.0.0". Since this includes all versions from 2.0 to infinity, >> and we are not currently addressing execution of two different versions of >> Tuscany side-by-side, the default looks sufficient. We could change it to >> "[2.0.0,3.0.0)" to make it more specific, but either way, it should be fine >> for now. >> >> I am still not entirely sure about versioning of 3rd party libraries >> distributed with Tuscany though. Since Tuscany is used to assemble SOA >> applications, Tuscany uses a large number of 3rd party libraries to provide >> different bindings and implementation types. Many of these 3rd party >> libraries may also be used by applications (either directly from Tuscany or >> from a different source). If for example, Tuscany's version of wsdl4j used >> import version "[1.6.2, 2.0,0)", and this version of Tuscany doesn't work >> with wsdl4j version 1.7, doesn't the version range "[1.6.2, 2.0,0)" prevent >> an application from installing and using version 1.7 along with Tuscany for >> something else? So should the version range only specifically include the >> version range that Tuscany has been tested against? And then we run into >> problems with too narrow version ranges. And what happens when an >> application is using wsdl4j from SpringSource or another repository where a >> different version range is included? How do we ensure that Tuscany and >> applications can all coexist? > > Ahh, and here we find that OSGi has the same achilles heel as Maven. I > anticipate that these kind of issues will be the basis for a shrill of > complaints as they are in Maven. > > I've had a fair bit of experience wiring in large sets of 3rd party jars. > No one follows any single kind of version nomenclature and many violate the > ones they espouse. > > Setting a version range in anticipation of what down stream application > assemblers will use will be a futile task. Only the Pope and my > mother-in-law are infallible and you're sure to get it wrong for some > significant part of your community. The best you can do is set the range > for what is safe for Tuscany in the hopes of providing accurate information > for down stream application assemblers. > > > Regards, > Alan > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
