yes you can, just make sure you're using the actual version and not a version range. The maven-bundle-plugin is set to use version ranges as default for your convenience. Just set the following in your maven properties:
<bnd.version.policy>[$(version;==;$(@)),$(version;+;$(@))) </bnd.version.policy> this does create with a version range. so setting to $(version;===) should most likely do, just play around with it :) regards, Achim 2014-02-19 15:38 GMT+01:00 Jeremy Jongsma <[email protected]>: > Maybe I'm not being very clear on how we're deploying. We deploy via > feature.xml files generated from a bundle's POM dependencies. So for > example: > > 1) feature1.xml is created from com.example:bundle1:1.0.0, and has a POM > dependency on com.example:test:1.0.1 > 2) feature2.xml is created from com.example:bundle2:2.0.0, and has a POM > dependency on com.example:test:1.0.2 > 3) Maven Bundle plugin has given both bundle1 and bundle2 manifests that > import com.example.test;version=[1.0,1.1) > 4) Start Karaf with both features, and Felix errors out saying there are > two paths to get to that dependency. Neither feature loads. > > Obviously we can't re-release every bundle/feature whenever a dependency > patch requires an update in one of our bundles. How are others dealing with > this? > > > On Wed, Feb 19, 2014 at 8:22 AM, Jeremy Jongsma <[email protected]>wrote: > >> Well yes, but it's also a big headache to maintain explicit >> Import-Packages blocks for large numbers of bundles, so we use the Maven >> Bundle plugin to automatically generate that for us, which defaults to >> version ranges for some reason. That makes it pretty easy for a micro >> version increment in one project's dependencies to mess up the wiring of >> another one. >> >> Unless I'm missing something with the bundle plugin that would make this >> easier. We can't be the only ones doing this? >> >> >> On Wed, Feb 19, 2014 at 2:18 AM, CLEMENT Jean-Philippe < >> [email protected]> wrote: >> >>> As far as I know OSGi allows to put version constraints :P ...so the >>> common bundles may exist in several versions and the right version will be >>> wired depending on the version constraints given by the config and the >>> application. >>> >>> >>> >>> Kind of usual business :) >>> >>> >>> >>> JP >>> >>> >>> >>> >>> >>> *De :* Jeremy Jongsma [mailto:[email protected]] >>> *Envoyé :* mardi 18 février 2014 22:22 >>> *À :* [email protected] >>> *Objet :* Application isolation within a Karaf instance >>> >>> >>> >>> Our server applications have two pieces: a configuration/update manager >>> and the application itself. The update manager is loaded as a bootstrap >>> feature, and the application is loaded as a normal feature. They are >>> completely separate and do not share any code, but they do have some common >>> bundle dependencies, which makes it susceptible to wiring conflicts if the >>> application uses a more recent version that the update manager supports. >>> Because of this we've had to start bundling the update manager in with all >>> of our applications, so that the application build will enforce the correct >>> bundle versions for the update manager also. >>> >>> >>> >>> Can Karaf provide full isolation of one feature from another, so that >>> all of their bundles and dependencies are invisible to the other and won't >>> trigger any wiring conflicts? We can tune our builds to deploy either KAR >>> and feature.xml files or anything else we need, as long as we can meet this >>> goal. >>> >> >> > -- Apache Karaf <http://karaf.apache.org/> Committer & PMC OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & Project Lead OPS4J Pax for Vaadin <http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project Lead blog <http://notizblog.nierbeck.de/>
