You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2009/09/07 09:59:37 UTC
OSGi bundles and versioning
I think we have a problem with lots (if not all) of bundles we've released.
Currently, they are importing their own package and do not use version
ranges.
Importing their own package may lead to real problems when deploying two
different versions of such a bundle. There is a high chance that the second
one will use the classes from the first one instead of their own classes.
Version ranges are also important to avoid some problems if the bundle is
wired to a dependent bundle with a new major version.
So I kinda think we need to update all the poms to change those and release
all those bundles.
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Fwd: OSGi bundles and versioning
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Yes, I see in the super POM.
OK to raise the Jira and make a first bundle.
Regards
JB
Guillaume Nodet wrote:
> I think it's already done IIRC.
>
> The bundles-pom/pom.xm has the following definition:
>
> <Export-Package>${servicemix.osgi.export}</Export-Package>
>
> with the default value for servicemix.osgi.export being:
>
> <servicemix.osgi.export>${servicemix.osgi.export.pkg}*;version=${pkgVersion};-split-package:=merge-first</servicemix.osgi.export>
>
> Bundles pom's usually just have to define servicemix.osgi.export.pkg and
> pkgVersion properties.
>
>
> On Mon, Sep 7, 2009 at 10:26, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> OK, it's clear now.
>>
>> Does it make sense to set the version in the export-package ?
>> Maybe we can add it into the pom.xml too, can't we ?
>>
>> Regards
>> JB
>>
>> Guillaume Nodet wrote:
>>
>>> No, it is used for imported packages to automatically generate a version
>>> range.
>>> The below policy will transform version=1.5 into version=[1.5,2) for any
>>> imported package.
>>>
>>> On Mon, Sep 7, 2009 at 10:22, Jean-Baptiste Onofré <jb@nanthrax.net<mailto:
>>> jb@nanthrax.net>> wrote:
>>>
>>> Hi Guillaume,
>>>
>>> thanks for the explanation.
>>>
>>> If I have right understood, the version policy in the super pom
>>> (using bundle plugin) automatically set the version of the export
>>> package, correct ? It's the same thing that doing it manually like
>>> this:
>>>
>>> <Export-Package>org.apache.commons.codec.*;version=${version}</Export-Package>
>>>
>>>
>>> I'm available to work on it.
>>>
>>>
>>> Regards
>>> JB
>>>
>>> Guillaume Nodet wrote:
>>>
>>> No, this isn't the only change required.
>>>
>>> First, we need to upgrade to the maven-bundle-plugin 2.0.0 (in
>>> the parent
>>> pom for all bundles).
>>> We need to add the following instruction for the maven bundle
>>> plugin:
>>>
>>>
>>> <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
>>>
>>> Then for each bundle, we need to make sure each package exported
>>> is not
>>> imported. For example, if we have:
>>> <Export-Package>org.apache.commons.codec*</Export-Package>
>>> we need to add the following to imports:
>>> !org.apache.commons.codec*
>>> This line needs to be added at the beginning of the Import-Package
>>> declaration.
>>>
>>> If we want to work on that, let me know when you've done the
>>> first bundle
>>> and we can check that everything is ok before modifying all the
>>> other ones.
>>>
>>> On Mon, Sep 7, 2009 at 10:06, Jean-Baptiste Onofré
>>> <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>>
>>> Hi Guillaume,
>>>
>>> you have right, I have seen it when working on the bundles
>>> required by CXF.
>>> I guess that we only need to add ;version=${version} in the
>>> pom.xml of each
>>> bundle.
>>>
>>> I doesn't see any Jira on this topic yes.
>>>
>>> If all are right with this change, I raise a Jira task and
>>> begin today.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> Guillaume Nodet wrote:
>>>
>>> I think we have a problem with lots (if not all) of
>>> bundles we've
>>> released.
>>> Currently, they are importing their own package and do
>>> not use version
>>> ranges.
>>>
>>> Importing their own package may lead to real problems
>>> when deploying two
>>> different versions of such a bundle. There is a high
>>> chance that the
>>> second
>>> one will use the classes from the first one instead of
>>> their own classes.
>>> Version ranges are also important to avoid some problems
>>> if the bundle is
>>> wired to a dependent bundle with a new major version.
>>>
>>> So I kinda think we need to update all the poms to
>>> change those and
>>> release
>>> all those bundles.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>>
>
>
Re: OSGi bundles and versioning
Posted by Lars Heinemann <lh...@apache.org>.
yeah, just wondered. The export was always done with the versioning info.
Lars
2009/9/7 Guillaume Nodet <gn...@gmail.com>:
> I think it's already done IIRC.
>
> The bundles-pom/pom.xm has the following definition:
>
> <Export-Package>${servicemix.osgi.export}</Export-Package>
>
> with the default value for servicemix.osgi.export being:
>
> <servicemix.osgi.export>${servicemix.osgi.export.pkg}*;version=${pkgVersion};-split-package:=merge-first</servicemix.osgi.export>
>
> Bundles pom's usually just have to define servicemix.osgi.export.pkg and
> pkgVersion properties.
>
>
> On Mon, Sep 7, 2009 at 10:26, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> OK, it's clear now.
>>
>> Does it make sense to set the version in the export-package ?
>> Maybe we can add it into the pom.xml too, can't we ?
>>
>> Regards
>> JB
>>
>> Guillaume Nodet wrote:
>>
>>> No, it is used for imported packages to automatically generate a version
>>> range.
>>> The below policy will transform version=1.5 into version=[1.5,2) for any
>>> imported package.
>>>
>>> On Mon, Sep 7, 2009 at 10:22, Jean-Baptiste Onofré <jb@nanthrax.net<mailto:
>>> jb@nanthrax.net>> wrote:
>>>
>>> Hi Guillaume,
>>>
>>> thanks for the explanation.
>>>
>>> If I have right understood, the version policy in the super pom
>>> (using bundle plugin) automatically set the version of the export
>>> package, correct ? It's the same thing that doing it manually like
>>> this:
>>>
>>> <Export-Package>org.apache.commons.codec.*;version=${version}</Export-Package>
>>>
>>>
>>> I'm available to work on it.
>>>
>>>
>>> Regards
>>> JB
>>>
>>> Guillaume Nodet wrote:
>>>
>>> No, this isn't the only change required.
>>>
>>> First, we need to upgrade to the maven-bundle-plugin 2.0.0 (in
>>> the parent
>>> pom for all bundles).
>>> We need to add the following instruction for the maven bundle
>>> plugin:
>>>
>>>
>>> <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
>>>
>>> Then for each bundle, we need to make sure each package exported
>>> is not
>>> imported. For example, if we have:
>>> <Export-Package>org.apache.commons.codec*</Export-Package>
>>> we need to add the following to imports:
>>> !org.apache.commons.codec*
>>> This line needs to be added at the beginning of the Import-Package
>>> declaration.
>>>
>>> If we want to work on that, let me know when you've done the
>>> first bundle
>>> and we can check that everything is ok before modifying all the
>>> other ones.
>>>
>>> On Mon, Sep 7, 2009 at 10:06, Jean-Baptiste Onofré
>>> <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>>
>>> Hi Guillaume,
>>>
>>> you have right, I have seen it when working on the bundles
>>> required by CXF.
>>> I guess that we only need to add ;version=${version} in the
>>> pom.xml of each
>>> bundle.
>>>
>>> I doesn't see any Jira on this topic yes.
>>>
>>> If all are right with this change, I raise a Jira task and
>>> begin today.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> Guillaume Nodet wrote:
>>>
>>> I think we have a problem with lots (if not all) of
>>> bundles we've
>>> released.
>>> Currently, they are importing their own package and do
>>> not use version
>>> ranges.
>>>
>>> Importing their own package may lead to real problems
>>> when deploying two
>>> different versions of such a bundle. There is a high
>>> chance that the
>>> second
>>> one will use the classes from the first one instead of
>>> their own classes.
>>> Version ranges are also important to avoid some problems
>>> if the bundle is
>>> wired to a dependent bundle with a new major version.
>>>
>>> So I kinda think we need to update all the poms to
>>> change those and
>>> release
>>> all those bundles.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>>
>>>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
http://lhein.blogspot.com
Fwd: OSGi bundles and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
I think it's already done IIRC.
The bundles-pom/pom.xm has the following definition:
<Export-Package>${servicemix.osgi.export}</Export-Package>
with the default value for servicemix.osgi.export being:
<servicemix.osgi.export>${servicemix.osgi.export.pkg}*;version=${pkgVersion};-split-package:=merge-first</servicemix.osgi.export>
Bundles pom's usually just have to define servicemix.osgi.export.pkg and
pkgVersion properties.
On Mon, Sep 7, 2009 at 10:26, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> OK, it's clear now.
>
> Does it make sense to set the version in the export-package ?
> Maybe we can add it into the pom.xml too, can't we ?
>
> Regards
> JB
>
> Guillaume Nodet wrote:
>
>> No, it is used for imported packages to automatically generate a version
>> range.
>> The below policy will transform version=1.5 into version=[1.5,2) for any
>> imported package.
>>
>> On Mon, Sep 7, 2009 at 10:22, Jean-Baptiste Onofré <jb@nanthrax.net<mailto:
>> jb@nanthrax.net>> wrote:
>>
>> Hi Guillaume,
>>
>> thanks for the explanation.
>>
>> If I have right understood, the version policy in the super pom
>> (using bundle plugin) automatically set the version of the export
>> package, correct ? It's the same thing that doing it manually like
>> this:
>>
>> <Export-Package>org.apache.commons.codec.*;version=${version}</Export-Package>
>>
>>
>> I'm available to work on it.
>>
>>
>> Regards
>> JB
>>
>> Guillaume Nodet wrote:
>>
>> No, this isn't the only change required.
>>
>> First, we need to upgrade to the maven-bundle-plugin 2.0.0 (in
>> the parent
>> pom for all bundles).
>> We need to add the following instruction for the maven bundle
>> plugin:
>>
>>
>> <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
>>
>> Then for each bundle, we need to make sure each package exported
>> is not
>> imported. For example, if we have:
>> <Export-Package>org.apache.commons.codec*</Export-Package>
>> we need to add the following to imports:
>> !org.apache.commons.codec*
>> This line needs to be added at the beginning of the Import-Package
>> declaration.
>>
>> If we want to work on that, let me know when you've done the
>> first bundle
>> and we can check that everything is ok before modifying all the
>> other ones.
>>
>> On Mon, Sep 7, 2009 at 10:06, Jean-Baptiste Onofré
>> <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>>
>> Hi Guillaume,
>>
>> you have right, I have seen it when working on the bundles
>> required by CXF.
>> I guess that we only need to add ;version=${version} in the
>> pom.xml of each
>> bundle.
>>
>> I doesn't see any Jira on this topic yes.
>>
>> If all are right with this change, I raise a Jira task and
>> begin today.
>>
>> Regards
>> JB
>>
>>
>> Guillaume Nodet wrote:
>>
>> I think we have a problem with lots (if not all) of
>> bundles we've
>> released.
>> Currently, they are importing their own package and do
>> not use version
>> ranges.
>>
>> Importing their own package may lead to real problems
>> when deploying two
>> different versions of such a bundle. There is a high
>> chance that the
>> second
>> one will use the classes from the first one instead of
>> their own classes.
>> Version ranges are also important to avoid some problems
>> if the bundle is
>> wired to a dependent bundle with a new major version.
>>
>> So I kinda think we need to update all the poms to
>> change those and
>> release
>> all those bundles.
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>>
>>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: OSGi bundles and versioning
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
OK, it's clear now.
Does it make sense to set the version in the export-package ?
Maybe we can add it into the pom.xml too, can't we ?
Regards
JB
Guillaume Nodet wrote:
> No, it is used for imported packages to automatically generate a version
> range.
> The below policy will transform version=1.5 into version=[1.5,2) for
> any imported package.
>
> On Mon, Sep 7, 2009 at 10:22, Jean-Baptiste Onofré <jb@nanthrax.net
> <ma...@nanthrax.net>> wrote:
>
> Hi Guillaume,
>
> thanks for the explanation.
>
> If I have right understood, the version policy in the super pom
> (using bundle plugin) automatically set the version of the export
> package, correct ? It's the same thing that doing it manually like
> this:
> <Export-Package>org.apache.commons.codec.*;version=${version}</Export-Package>
>
>
> I'm available to work on it.
>
>
> Regards
> JB
>
> Guillaume Nodet wrote:
>
> No, this isn't the only change required.
>
> First, we need to upgrade to the maven-bundle-plugin 2.0.0 (in
> the parent
> pom for all bundles).
> We need to add the following instruction for the maven bundle
> plugin:
>
>
> <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
>
> Then for each bundle, we need to make sure each package exported
> is not
> imported. For example, if we have:
> <Export-Package>org.apache.commons.codec*</Export-Package>
> we need to add the following to imports:
> !org.apache.commons.codec*
> This line needs to be added at the beginning of the Import-Package
> declaration.
>
> If we want to work on that, let me know when you've done the
> first bundle
> and we can check that everything is ok before modifying all the
> other ones.
>
> On Mon, Sep 7, 2009 at 10:06, Jean-Baptiste Onofré
> <jb@nanthrax.net <ma...@nanthrax.net>> wrote:
>
> Hi Guillaume,
>
> you have right, I have seen it when working on the bundles
> required by CXF.
> I guess that we only need to add ;version=${version} in the
> pom.xml of each
> bundle.
>
> I doesn't see any Jira on this topic yes.
>
> If all are right with this change, I raise a Jira task and
> begin today.
>
> Regards
> JB
>
>
> Guillaume Nodet wrote:
>
> I think we have a problem with lots (if not all) of
> bundles we've
> released.
> Currently, they are importing their own package and do
> not use version
> ranges.
>
> Importing their own package may lead to real problems
> when deploying two
> different versions of such a bundle. There is a high
> chance that the
> second
> one will use the classes from the first one instead of
> their own classes.
> Version ranges are also important to avoid some problems
> if the bundle is
> wired to a dependent bundle with a new major version.
>
> So I kinda think we need to update all the poms to
> change those and
> release
> all those bundles.
>
>
>
>
>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
>
Re: OSGi bundles and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
No, it is used for imported packages to automatically generate a version
range.
The below policy will transform version=1.5 into version=[1.5,2) for any
imported package.
On Mon, Sep 7, 2009 at 10:22, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Guillaume,
>
> thanks for the explanation.
>
> If I have right understood, the version policy in the super pom (using
> bundle plugin) automatically set the version of the export package, correct
> ? It's the same thing that doing it manually like this:
> <Export-Package>org.apache.commons.codec.*;version=${version}</Export-Package>
>
>
> I'm available to work on it.
>
>
> Regards
> JB
>
> Guillaume Nodet wrote:
>
>> No, this isn't the only change required.
>>
>> First, we need to upgrade to the maven-bundle-plugin 2.0.0 (in the parent
>> pom for all bundles).
>> We need to add the following instruction for the maven bundle plugin:
>>
>>
>> <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
>>
>> Then for each bundle, we need to make sure each package exported is not
>> imported. For example, if we have:
>> <Export-Package>org.apache.commons.codec*</Export-Package>
>> we need to add the following to imports:
>> !org.apache.commons.codec*
>> This line needs to be added at the beginning of the Import-Package
>> declaration.
>>
>> If we want to work on that, let me know when you've done the first bundle
>> and we can check that everything is ok before modifying all the other
>> ones.
>>
>> On Mon, Sep 7, 2009 at 10:06, Jean-Baptiste Onofré <jb...@nanthrax.net>
>> wrote:
>>
>> Hi Guillaume,
>>>
>>> you have right, I have seen it when working on the bundles required by
>>> CXF.
>>> I guess that we only need to add ;version=${version} in the pom.xml of
>>> each
>>> bundle.
>>>
>>> I doesn't see any Jira on this topic yes.
>>>
>>> If all are right with this change, I raise a Jira task and begin today.
>>>
>>> Regards
>>> JB
>>>
>>>
>>> Guillaume Nodet wrote:
>>>
>>> I think we have a problem with lots (if not all) of bundles we've
>>>> released.
>>>> Currently, they are importing their own package and do not use version
>>>> ranges.
>>>>
>>>> Importing their own package may lead to real problems when deploying two
>>>> different versions of such a bundle. There is a high chance that the
>>>> second
>>>> one will use the classes from the first one instead of their own
>>>> classes.
>>>> Version ranges are also important to avoid some problems if the bundle
>>>> is
>>>> wired to a dependent bundle with a new major version.
>>>>
>>>> So I kinda think we need to update all the poms to change those and
>>>> release
>>>> all those bundles.
>>>>
>>>>
>>>>
>>>>
>>
>>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: OSGi bundles and versioning
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Guillaume,
thanks for the explanation.
If I have right understood, the version policy in the super pom (using
bundle plugin) automatically set the version of the export package,
correct ? It's the same thing that doing it manually like this:
<Export-Package>org.apache.commons.codec.*;version=${version}</Export-Package>
I'm available to work on it.
Regards
JB
Guillaume Nodet wrote:
> No, this isn't the only change required.
>
> First, we need to upgrade to the maven-bundle-plugin 2.0.0 (in the parent
> pom for all bundles).
> We need to add the following instruction for the maven bundle plugin:
>
> <_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
>
> Then for each bundle, we need to make sure each package exported is not
> imported. For example, if we have:
> <Export-Package>org.apache.commons.codec*</Export-Package>
> we need to add the following to imports:
> !org.apache.commons.codec*
> This line needs to be added at the beginning of the Import-Package
> declaration.
>
> If we want to work on that, let me know when you've done the first bundle
> and we can check that everything is ok before modifying all the other ones.
>
> On Mon, Sep 7, 2009 at 10:06, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
>
>> Hi Guillaume,
>>
>> you have right, I have seen it when working on the bundles required by CXF.
>> I guess that we only need to add ;version=${version} in the pom.xml of each
>> bundle.
>>
>> I doesn't see any Jira on this topic yes.
>>
>> If all are right with this change, I raise a Jira task and begin today.
>>
>> Regards
>> JB
>>
>>
>> Guillaume Nodet wrote:
>>
>>> I think we have a problem with lots (if not all) of bundles we've
>>> released.
>>> Currently, they are importing their own package and do not use version
>>> ranges.
>>>
>>> Importing their own package may lead to real problems when deploying two
>>> different versions of such a bundle. There is a high chance that the
>>> second
>>> one will use the classes from the first one instead of their own classes.
>>> Version ranges are also important to avoid some problems if the bundle is
>>> wired to a dependent bundle with a new major version.
>>>
>>> So I kinda think we need to update all the poms to change those and
>>> release
>>> all those bundles.
>>>
>>>
>>>
>
>
Re: OSGi bundles and versioning
Posted by Guillaume Nodet <gn...@gmail.com>.
No, this isn't the only change required.
First, we need to upgrade to the maven-bundle-plugin 2.0.0 (in the parent
pom for all bundles).
We need to add the following instruction for the maven bundle plugin:
<_versionpolicy>[$(version;==;$(@)),$(version;+;$(@)))</_versionpolicy>
Then for each bundle, we need to make sure each package exported is not
imported. For example, if we have:
<Export-Package>org.apache.commons.codec*</Export-Package>
we need to add the following to imports:
!org.apache.commons.codec*
This line needs to be added at the beginning of the Import-Package
declaration.
If we want to work on that, let me know when you've done the first bundle
and we can check that everything is ok before modifying all the other ones.
On Mon, Sep 7, 2009 at 10:06, Jean-Baptiste Onofré <jb...@nanthrax.net> wrote:
> Hi Guillaume,
>
> you have right, I have seen it when working on the bundles required by CXF.
> I guess that we only need to add ;version=${version} in the pom.xml of each
> bundle.
>
> I doesn't see any Jira on this topic yes.
>
> If all are right with this change, I raise a Jira task and begin today.
>
> Regards
> JB
>
>
> Guillaume Nodet wrote:
>
>> I think we have a problem with lots (if not all) of bundles we've
>> released.
>> Currently, they are importing their own package and do not use version
>> ranges.
>>
>> Importing their own package may lead to real problems when deploying two
>> different versions of such a bundle. There is a high chance that the
>> second
>> one will use the classes from the first one instead of their own classes.
>> Version ranges are also important to avoid some problems if the bundle is
>> wired to a dependent bundle with a new major version.
>>
>> So I kinda think we need to update all the poms to change those and
>> release
>> all those bundles.
>>
>>
>>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: OSGi bundles and versioning
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Guillaume,
you have right, I have seen it when working on the bundles required by CXF.
I guess that we only need to add ;version=${version} in the pom.xml of
each bundle.
I doesn't see any Jira on this topic yes.
If all are right with this change, I raise a Jira task and begin today.
Regards
JB
Guillaume Nodet wrote:
> I think we have a problem with lots (if not all) of bundles we've released.
> Currently, they are importing their own package and do not use version
> ranges.
>
> Importing their own package may lead to real problems when deploying two
> different versions of such a bundle. There is a high chance that the second
> one will use the classes from the first one instead of their own classes.
> Version ranges are also important to avoid some problems if the bundle is
> wired to a dependent bundle with a new major version.
>
> So I kinda think we need to update all the poms to change those and release
> all those bundles.
>
>