Ability to specify package version range using maven-bundle-plugin

[Sahoo <Sa...@Sun.COM>]

AFAIK, in the absence of any version attribute specification in 
Import-Package instruction, maven-bundle-plugin generates package 
version constraint in the following manner:
1. If the imported package "p" has version "x.y.z", then it generates 
Import-Package: p, version="x.y.z",
2. If the imported package "p" has no version, then it generates 
Import-Package: p.

What are the ways to specify an upper bound? I know I can specify the 
exact version range using Import-Package instruction. Is there any other 
way? I don't think so, but I want some knowledgeable user to confirm the 
same.

If this is indeed true, then does it not look a bit limiting? Should 
there not be a way to attach a custom versioning policy to calculate the 
version range? To give an example, the policy can be that in a version 
scheme that uses dew decimal numbers to specify version, only a change 
in major number is considered backward compatible. In that case, the 
version range should be generated as [x.y.z, x+1).

Thanks,
Sahoo

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org

Re: Ability to specify package version range using maven-bundle-plugin

[Stuart McCulloch <st...@jayway.net>]

2008/7/11 Sahoo <Sa...@sun.com>:

> AFAIK, in the absence of any version attribute specification in
> Import-Package instruction, maven-bundle-plugin generates package version
> constraint in the following manner:
> 1. If the imported package "p" has version "x.y.z", then it generates
> Import-Package: p, version="x.y.z",
> 2. If the imported package "p" has no version, then it generates
> Import-Package: p.
>

well it's actually Bnd generating the constraints, but yes that's correct -
the bundleplugin
passes the Maven compilation classpath (excluding provided dependencies) to
Bnd and
Bnd uses information from the various jars, like packageinfo, etc. to add
versions


> What are the ways to specify an upper bound? I know I can specify the exact
> version range using Import-Package instruction. Is there any other way? I
> don't think so, but I want some knowledgeable user to confirm the same.
>

currently the only way to add an upper bound is to explicitly set it via
Import-Package.

  http://aqute.biz/Code/Bnd#import-package

Bnd will allow you to write something like:
org.osgi.framework;version="[${@},2.0)"
where the ${@} expands to the exact version found on the classpath, but it
doesn't
yet support a general rule, like "[x.y.z, x+1]" which I agree would be
useful


> If this is indeed true, then does it not look a bit limiting? Should there
> not be a way to attach a custom versioning policy to calculate the version
> range? To give an example, the policy can be that in a version scheme that
> uses dew decimal numbers to specify version, only a change in major number
> is considered backward compatible. In that case, the version range should be
> generated as [x.y.z, x+1).
>

feel free to suggest a setting / some sort of instruction notation to
support this:

  http://issues.apache.org/jira/browse/FELIX/component/12311143

set the fix version to "1.4.3" as this is the release I'm using for
Bnd-related changes.


> Thanks,
> Sahoo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>


-- 
Cheers, Stuart