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. > ------------------------------------------------------------
