I had several talks after I presented the Sling tooling at OSGiCon some years ago, the feedback ranged from interesting to unusable because of exactly this problem. For example if you want to provide an upgrade path, it sometimes makes sense to install two versions of an API, let the users migrate and then remove the old version.
Now, the easiest criteria would be to support the same bundle with different major versions - if semantic versioning is applied and export/import statements are done correctly, this shouldn't cause any problem at all, as everything gets wired correctly. But there are already some "if"s in this sentence and then, the bundle version is usually different from the package versions contained in the bundle. Carsten 2014-03-01 11:01 GMT+01:00 Thomas Joseph <[email protected]>: > I agree with you Justin, that this may be a drastic change and we need a > mechanism to identify install vs update for the Sling tooling. One idea > could be use a custom manifest entry for it, in the absence of this > manifest entry in the bundles, adopt one of install or update by the sling > tooling. > > This way the "system" bundles can go for "update" policy while the > application bundles can choose to have "install" policy, thereby allowing > multiple versions by Sling applications if so desired. > > WDYT? > > > On Sat, Mar 1, 2014 at 6:31 AM, Justin Edelson <[email protected] > >wrote: > > > Hi, > > I think in general, this kind of change in our tooling would be > > problematic. While there are cases for deploying multiple versions of > > the same bundle, for tooling to *automatically* detect that this is > > desired is tricky and IMHO likely to be error prone. > > > > Is there a concrete proposal somewhere for how an administrator would > > declare that a bundle is not meant to replace an existing bundle (i.e. > > install vs. update)? > > > > Regards, > > Justin > > > > On Fri, Feb 28, 2014 at 12:35 PM, Thomas Joseph <[email protected]> > > wrote: > > > Hi Carsten, > > > > > > What were the design consideration for restricting multiple versions of > > an > > > OSGi bundle in the sling tooling - while this is an inherent and > > > "celebrated" feature natively available in OSGi? There are many use > cases > > > where we would want to have this feature in place, and still use Sling. > > > > > > Although if I understand it right, we can by-pass this feature by not > > using > > > the sling tooling, and rather use our own mechanism (eg using > > fileinstall) > > > to have multiple versions of file in the system, I would vote for > having > > > this restriction removed from the Sling tooling. > > > > > > > > > On Fri, Feb 28, 2014 at 1:47 PM, Carsten Ziegeler < > [email protected] > > >wrote: > > > > > >> Hi, > > >> > > >> > > >> the tooling we have (launchpad, Sling's OSGi installer) both don't > > support > > >> multiple versions of a bundle. > > >> You can workaround the launchpad restriction by using a different > > artifact > > >> or group id, this will include the bundle in the launchpad. > > >> However, the OSGi installer always installs only the highest version > of > > a > > >> bundle - you can workaround this by using different symbolic names. > > >> > > >> Or in other words, you would need to repackage one of the bundles and > > >> deploy it under different maven coordinates into your repository. > > >> > > >> We received a lot of feedback over the past years and people always > > >> stumbled across these restrictions, so maybe it would make sense to > > support > > >> bundles with different major versions in our tooling. > > >> > > >> Carsten > > >> > > >> > > >> 2014-02-28 8:57 GMT+01:00 Rupert Westenthaler <[email protected]>: > > >> > > >> > Hi all, > > >> > > > >> > I cam around a problem I am not sure how to solve. Maybe someone can > > >> > here knows an workaround. > > >> > > > >> > The ServiceMix Bundle for JDOM2 [1] imports packages provides by the > > >> > ServiceMix Bundle for JDOM 1.1 [2]. So to use JDOM I would need to > > >> > have the bundles of both versions included in my Launcher. > > >> > > > >> > However the Maven Launchpad Plugin does not allow to BundleLists to > > >> > include different versions for the same Bundle as clearly stated by > > >> > [3]. > > >> > > > >> > Is there any possibility to tell the Launchpad Plugin to include > both > > >> > JDOM bundles? > > >> > > > >> > best > > >> > Rupert > > >> > > > >> > > > >> > [1] > > >> > > > >> > > > http://search.maven.org/#artifactdetails|org.apache.servicemix.bundles|org.apache.servicemix.bundles.jdom|2.0.2_1|bundle > > >> > [2] > > >> > > > >> > > > http://search.maven.org/#artifactdetails|org.apache.servicemix.bundles|org.apache.servicemix.bundles.jdom|1.1.2_1|bundle > > >> > ] > > >> > [3] > > >> > > > >> > -- > > >> > | Rupert Westenthaler [email protected] > > >> > | Bodenlehenstraße 11 ++43-699-11108907 > > >> > | A-5500 Bischofshofen > > >> > > > >> > > >> > > >> > > >> -- > > >> Carsten Ziegeler > > >> [email protected] > > >> > > > > > > > > > > > > -- > > > Thanks and Regards, > > > /Thomas Joseph > > > > > > > > > ------------------------------------------------------------ > > > Promote Open Source - Promote Liberty of Ideas and Software. > > > ------------------------------------------------------------ > > > > > > -- > Thanks and Regards, > /Thomas Joseph > > LinkedIn: http://www.linkedin.com/in/ethomasjoseph > Twitter: http://twitter.com/ethomasjoseph > > ------------------------------------------------------------ > Promote Open Source - Promote Liberty of Ideas and Software. > ------------------------------------------------------------ > -- Carsten Ziegeler [email protected]
