New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ease the packaging of bundle when depending on bundle forward compatible #449

Closed
cescoffier opened this Issue Mar 4, 2015 · 1 comment

Comments

Projects
None yet
1 participant
@cescoffier
Member

cescoffier commented Mar 4, 2015

Right now, when a project depends on a bundle that has a not standard versioning scheme, the generated import-package can be problematic.

For example, if your project depends on Guava 15, it generates a range [15, 16), and so does not let you use a recent version fo Guava.

I propose to analyse the version scheme and remove the upper bound of the range on these import. Obviously, this feature can be disabled, and a warning will be printed.

@cescoffier cescoffier self-assigned this Mar 4, 2015

@cescoffier cescoffier added this to the 0.7.1 milestone Mar 4, 2015

@cescoffier

This comment has been minimized.

Show comment
Hide comment
@cescoffier

cescoffier Mar 8, 2015

Member

To fix this issue, I've proposed a BND plugin analyzing specified packages and adapting the version. It's made to avoid the generation of upper bound range when the artifacts is forward compatible.

The feature is activated by default and adapt the Guava imports to remove the upper bound. It is possible to add other packages to the list of fixed ranges by creating a src/main/osgi/versions.properties file:

# Custom version file checking the three types of syntax

# version => no upper bound
org.joda.time=2.6.0

# range => as given
org.apache.felix.ipojo*=[1.12, 3)

# no value, range generated with lower bound found in classpath
org.mockito

When a range is set, the range is used. When just a version is set, if generate a range without upper bound. When nothing is set, it look for a provider in the classpath, extract the version and create a range with the found version as lower bound, and no upper bound.

Member

cescoffier commented Mar 8, 2015

To fix this issue, I've proposed a BND plugin analyzing specified packages and adapting the version. It's made to avoid the generation of upper bound range when the artifacts is forward compatible.

The feature is activated by default and adapt the Guava imports to remove the upper bound. It is possible to add other packages to the list of fixed ranges by creating a src/main/osgi/versions.properties file:

# Custom version file checking the three types of syntax

# version => no upper bound
org.joda.time=2.6.0

# range => as given
org.apache.felix.ipojo*=[1.12, 3)

# no value, range generated with lower bound found in classpath
org.mockito

When a range is set, the range is used. When just a version is set, if generate a range without upper bound. When nothing is set, it look for a provider in the classpath, extract the version and create a range with the found version as lower bound, and no upper bound.

@cescoffier cescoffier closed this in abb1bc4 Mar 8, 2015

@cescoffier cescoffier changed the title from Ease the packaging of bundle when depending on bundle not using SemVer to Ease the packaging of bundle when depending on bundle forward compatible Mar 8, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment