Multiple versions of OSGI Bundles with BundleLists
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 Westenthalerrwes...@apache.org | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
Re: Multiple versions of OSGI Bundles with BundleLists
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 : > 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 Westenthalerrwes...@apache.org > | Bodenlehenstraße 11 ++43-699-11108907 > | A-5500 Bischofshofen > -- Carsten Ziegeler cziege...@apache.org
Re: Multiple versions of OSGI Bundles with BundleLists
Thx Carsten for the information. I was expecting this answer. On Fri, Feb 28, 2014 at 9:17 AM, Carsten Ziegeler 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. > I think I will create my own JDOM bundle. best Rupert > 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 : > >> 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 Westenthalerrwes...@apache.org >> | Bodenlehenstraße 11 ++43-699-11108907 >> | A-5500 Bischofshofen >> > > > > -- > Carsten Ziegeler > cziege...@apache.org -- | Rupert Westenthalerrwes...@apache.org | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
Re: Multiple versions of OSGI Bundles with BundleLists
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 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 : > > > 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 Westenthalerrwes...@apache.org > > | Bodenlehenstraße 11 ++43-699-11108907 > > | A-5500 Bischofshofen > > > > > > -- > Carsten Ziegeler > cziege...@apache.org > -- Thanks and Regards, /Thomas Joseph Promote Open Source - Promote Liberty of Ideas and Software.
Re: Multiple versions of OSGI Bundles with BundleLists
On 28.02.2014, at 09:35, Thomas Joseph wrote: > 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. I think (without having tried multiple versions in practice) this would be rather dangerous in reality. It only makes sense for 3rd party helper libraries - say a logging API or some commons utility. Once you have core API modules of your application with usually singleton services, you really only want a single instance to be running at the same time. Managing different versions of those 3rd party libraries can be nicely done using embedding them in bundles, thus hiding their presence from all the other bundles. This works pretty good. Cheers, Alex
Re: Multiple versions of OSGI Bundles with BundleLists
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 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 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 : >> >> > 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 Westenthalerrwes...@apache.org >> > | Bodenlehenstraße 11 ++43-699-11108907 >> > | A-5500 Bischofshofen >> > >> >> >> >> -- >> Carsten Ziegeler >> cziege...@apache.org >> > > > > -- > Thanks and Regards, > /Thomas Joseph > > > > Promote Open Source - Promote Liberty of Ideas and Software. >
Re: Multiple versions of OSGI Bundles with BundleLists
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 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 > 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 >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 : > >> > >> > 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 Westenthalerrwes...@apache.org > >> > | Bodenlehenstraße 11 ++43-699-11108907 > >> > | A-5500 Bischofshofen > >> > > >> > >> > >> > >> -- > >> Carsten Ziegeler > >> cziege...@apache.org > >> > > > > > > > > -- > > 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.
Re: Multiple versions of OSGI Bundles with BundleLists
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 : > 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 >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 > > 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 < > cziege...@apache.org > > >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 : > > >> > > >> > 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 Westenthalerrwes...@apache.org > > >> > | Bodenlehenstraße 11 ++43-699-11108907 > > >> > | A-5500 Bischofshofen > > >> > > > >> > > >> > > >> > > >> -- > > >> Carsten Ziegeler > > >> cziege...@apache.org > >
