Redundant "org.osgi.framework" dependency in version 6.1

[alexey-anufriev]

Dozer v6.1 cannot be launched in OSGi environment.
The bundle cannot start because it has the following dependency inside MANIFEST file:

org.osgi.framework;version="[1.8,2)"

But this dependency should not appear in the list at all because all the required classes from this package are already provided by osgi.core library.

It seems that this packages is added during bundling process indirectly.

[garethahealy]

@orange-buffalo ; are you guys using 6.1 in your OSGi env?

[garethahealy]

@Ice-pro ; what OSGi container and version are you using? i.e.: karaf 4?

[orange-buffalo]

@garethahealy, actually, we're using 5.0.0 (JBoss Fuse 6.2). Maybe we could make Dozer less opinionated about OSGi version, declaring [4,7) in manifest.. As far as I remember, we do not use too much from OSGi API.

[alexey-anufriev]

@garethahealy, please take into account the answer from @orange-buffalo, we are from the same teams

[garethahealy]

@orange-buffalo ; am fine with widening OSGi versions. If you guys are happy to raise a PR, it would be nice if we can create a dozer-osgi-karaf2-tests and dozer-osgi-karaf4-tests, to check its deployable to both containers.

i.e.: karaf2 for now, and karaf4 for future.

Am ignoring karaf3, as it seems most people have skipped and gone straight to 4 from 2.

[orange-buffalo]

@garethahealy sure, we will try to prepare the PR. Would it be possible to release a new version after this PR is accepted (if required, it could be 6.1.1 instead of 6.2)?

[garethahealy]

@orange-buffalo ; some of the deprecated methods are no longer there (getters and setters on the mapper), so since there are API changes, would prefer it to be 6.2.

I'd also rather not create a branch of the 6.1 tag, as since theres only a few committers, its easier to keep moving forward.

[orange-buffalo]

@garethahealy, it looks like Pax Exam supports only one single container in classpath, thus having tests with both Karaf and Pax Exam Native in the same maven module is not possible. We should either create a separate maven module for Karaf tests (which makes it complicated to share actual test code), or drop Pax Exam Native (anyway Karaf is much closer to real-world usages), or implement maven profiles to enable dependencies to different containers (which complicates the test infrastructure). Would you be okay with replacing Pax Exam Native with Karaf?

[garethahealy]

@orange-buffalo ; yeah, am happy moving from native to karaf.