The bnd page has documentation to it, as the maven-bundle-plugin uses BND for the generation of the manifest. See [1].
regards, Achim [1] - http://www.aqute.biz/Bnd/Macros 2014-02-19 15:59 GMT+01:00 Jeremy Jongsma <[email protected]>: > Thank you, I did not know about that option! Where is that documented? I > tried searching for this now that I know about it, and didn't find many > results. > > > On Wed, Feb 19, 2014 at 8:47 AM, Achim Nierbeck > <[email protected]>wrote: > >> 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/> >> > > -- 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/>
