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/> >
