You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Carlos Sanchez <ca...@apache.org> on 2007/09/06 19:39:04 UTC
Version resolution and optional package imports
I have a couple of concept questions for improvements to the bundle
plugin manifest generation
* Version resolution
Let's say bundle A exports a package with version 2.0, and bundle B
imports that package version 1.0
When B is started, will it fail because A 1.0 is not present?
Is the same behavior for Require-Bundle and Import-Package ?
I guess if B imports [1.0,) then it'd work
* Optional packages
If a bundle imports packages from several bundles A,B,C... but only
one is required at runtime, will it work? or should it explicitly say
that they are optional (resolution:=optional) ?
ie. commons-logging imports log4j, java logging,... but only on will
likely be present at runtime
https://svn.apache.org/repos/asf/felix/trunk/commons/commons-logging/pom.xml
Thanks
--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride
Re: Version resolution and optional package imports
Posted by Stuart McCulloch <st...@jayway.net>.
FYI, there's also a minor difference between OSGi and Maven:
1.0.0-SNAPSHOT < 1.0.0 in Maven
but
1.0.0.SNAPSHOT > 1.0.0 in OSGi
which can sometimes lead to confusion during development :)
On 07/09/2007, Felix Meschberger <fm...@gmail.com> wrote:
>
> Am Freitag, den 07.09.2007, 11:11 +0800 schrieb Stuart McCulloch:
> > On 07/09/07, Carlos Sanchez <ca...@apache.org> wrote:
> > >
> > > I have a couple of concept questions for improvements to the bundle
> > > plugin manifest generation
> > >
> > > * Version resolution
> > > Let's say bundle A exports a package with version 2.0, and bundle B
> > > imports that package version 1.0
> > >
> > > When B is started, will it fail because A 1.0 is not present?
> >
> >
> > yes, unless another bundle provides version 1.0
>
> Well, not quite: If B specifies the import as version=1.0, this means
> any version >= 1.0. So, yes, bundle B will resolve the package using the
> export from Bundle A in this case.
>
> > * Optional packages
> > > If a bundle imports packages from several bundles A,B,C... but only
> > > one is required at runtime, will it work?
>
> But keep in mind: A bundle imports packages and does not care where
> these packages come from. This is very important and very useful but
> might be somewhat strange at first sight. But if you look behind the
> scenes it makes sense a lot.
>
> > yes, if only one will be available - or you could use
> DynamicImport-Package
> > (but if you know the packages up front, then imho Import-Package is
> better)
>
> resolution:=optional imports are tried to resolve when the bundle is
> resolved. If the fail to resolve, they are just ignored and may only
> become available when the bundle is resolved again (probably due to a
> PackageAdmin refresh). DynamicImport-Package imports on the other hand
> are not resolved up-front when the bundle is resolved. They are only
> resolved when actually needed and will be re-checked as long as they
> cannot be resolved. Of course after being resolved, the
> DynamicImport-Package imports remain wired until the bundle is being
> resolved again.
>
> At the end of the day, I agree with Stuart, that resolution:=optional
> tends to be clearer and possibly more performant. But your milage and
> use cases may vary.
>
> Regards
> Felix
>
>
--
Cheers, Stuart
Re: Version resolution and optional package imports
Posted by Felix Meschberger <fm...@gmail.com>.
Am Freitag, den 07.09.2007, 11:11 +0800 schrieb Stuart McCulloch:
> On 07/09/07, Carlos Sanchez <ca...@apache.org> wrote:
> >
> > I have a couple of concept questions for improvements to the bundle
> > plugin manifest generation
> >
> > * Version resolution
> > Let's say bundle A exports a package with version 2.0, and bundle B
> > imports that package version 1.0
> >
> > When B is started, will it fail because A 1.0 is not present?
>
>
> yes, unless another bundle provides version 1.0
Well, not quite: If B specifies the import as version=1.0, this means
any version >= 1.0. So, yes, bundle B will resolve the package using the
export from Bundle A in this case.
> * Optional packages
> > If a bundle imports packages from several bundles A,B,C... but only
> > one is required at runtime, will it work?
But keep in mind: A bundle imports packages and does not care where
these packages come from. This is very important and very useful but
might be somewhat strange at first sight. But if you look behind the
scenes it makes sense a lot.
> yes, if only one will be available - or you could use DynamicImport-Package
> (but if you know the packages up front, then imho Import-Package is better)
resolution:=optional imports are tried to resolve when the bundle is
resolved. If the fail to resolve, they are just ignored and may only
become available when the bundle is resolved again (probably due to a
PackageAdmin refresh). DynamicImport-Package imports on the other hand
are not resolved up-front when the bundle is resolved. They are only
resolved when actually needed and will be re-checked as long as they
cannot be resolved. Of course after being resolved, the
DynamicImport-Package imports remain wired until the bundle is being
resolved again.
At the end of the day, I agree with Stuart, that resolution:=optional
tends to be clearer and possibly more performant. But your milage and
use cases may vary.
Regards
Felix
Re: Version resolution and optional package imports
Posted by Stuart McCulloch <st...@jayway.net>.
On 07/09/07, Carlos Sanchez <ca...@apache.org> wrote:
>
> I have a couple of concept questions for improvements to the bundle
> plugin manifest generation
>
> * Version resolution
> Let's say bundle A exports a package with version 2.0, and bundle B
> imports that package version 1.0
>
> When B is started, will it fail because A 1.0 is not present?
yes, unless another bundle provides version 1.0
Is the same behavior for Require-Bundle and Import-Package ?
yes
I guess if B imports [1.0,) then it'd work
yes - as long as version 2.0 is backwards compatible with 1.0 ;)
btw, take a look at http://www.aqute.biz/Code/Bnd#import-package
for how to use automatically detected versions (from the classpath)
with ranges in Bnd
* Optional packages
> If a bundle imports packages from several bundles A,B,C... but only
> one is required at runtime, will it work?
only if all packages are available at runtime
or should it explicitly say
> that they are optional (resolution:=optional) ?
yes, if only one will be available - or you could use DynamicImport-Package
(but if you know the packages up front, then imho Import-Package is better)
ie. commons-logging imports log4j, java logging,... but only on will
> likely be present at runtime
>
> https://svn.apache.org/repos/asf/felix/trunk/commons/commons-logging/pom.xml
yep - I typically mark those commons-logging dependencies as optional
Thanks
HTH
--
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
> -- The Princess Bride
>
--
Cheers, Stuart