That is interesting but requires the introduction of OSGi version dependencies.
But currently we do not use them and as a consequence we do not know the impact of a version increase. The OSGi version carry more semantic information. Some increases do not break the API while others do. We only version bundles as a whole in maven. So a 0.1 -> 0.2 increase can be a bug fix in an implementation class or an API change (that may or may not be backwards compatible). But it means depending on different version can be managed in the OSGi container. But how do you handle maven version numbers? In order for this to make sense I think you handle versions manually per module. That means after a release you do not make the module depend on the latest SNAPSHOT versions of all its dependencies but rather you stick with the oldest release version you depended on and only increment to the next SNAPSHOT when you require new features or some other reason may require an update (e.g. major version change). On 19 March 2012 13:35, Bertrand Delacretaz <[email protected]> wrote: > On Mon, Mar 19, 2012 at 12:34 PM, Daniel Spicar <[email protected]> > wrote: > > ...the > > potential problem here is that let's say two bundles depend on rdf.core > but > > different versions of it. That may cause trouble in the OSGi > container.... > > Not necessarily - bundle dependencies should point to API bundles (or > at least API packages), and it's a good idea to have a bundle depend > on the oldest version that it can accept. > > So if you have for example > > bundle A requires foo API 1.1 > bundle B requires foo API 1.2 > > both can happily run in a system which provides foo API 1.2 - and the > implementation bundle of that API could be V2.5, as long as the API > hasn't changed it doesn't matter. > > The way we handle this in Sling is that bundles depend on the oldest > version of a package that they actually require, and we don't update > these dependencies unless really required. This means different > bundles might depend on different versions from a given API, but that > doesn't really matter. > > The only exception is the Sling launcher jar module, which always > depends on the latest versions of everything so that we distribute the > latest stuff. > > -Bertrand >
