In my opinion, the benefits of the bnd-maven-plugin vs the maven-bundle-plugin are:
- Easier configuration You configure the bnd-maven-plugin just like you configure BND - there isn’t any strange XML mapping to BND configuration. Also, it keeps the OSGi configuration separate from the build configuration - in the bnd.bnd file. - Better performance (maybe) I haven’t verified this for the new build setup with the “lightweight” process, but building my own projects using the bnd-maven-plugin was significantly faster than using the maven-bundle-plugin. - Active community While I’ve been trying this out, the BND community has been very responsive and helpful - even when I mistakenly posted to a closed topic. I still haven’t heard anything about the bug in the maven-bundle-plugin I reported, and I even submitted a patch for it. I think either will work for us - the “lightweight” build process gets us out of the custom packaging required by the “bundle” type, and we don’t have the situation in the Camel build that the maven-bundle-plugin just doesn’t work for (Blueprint files in alternate locations combined with bundle fragments - a pretty far-out edge-case I know, but it’s what I had to do). Neil Bartlett’s post explained why the plugin came about ( http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html <http://njbartlett.name/2015/03/27/announcing-bnd-maven-plugin.html> ). I’ve switched to the bnd-maven-plugin because it’s easier for me to deal with than the maven-bundle-plugin. The implicit exclusion of certain packages, and the automatic export of packages have been very problematic for me. I like the fact that the bnd-maven-plugin forces me to specify what I want exported - I have to think about that - and deciding which packages to export packages to export should be a decision with some thought behind it. > On Apr 6, 2016, at 1:53 AM, Raul Kripalani <ra...@apache.org> wrote: > > I agree with you guys. I have doubts whether going the bnd-maven-plugin > brings in any actual benefits vs our current setup. > > Now that we use the "lightweight" process anyway (no 'bundle' extensions, > just generating the manifest), both approaches got to be functionally > equivalent, aside from minor differences like the ones pointed out. At the > end of the day, it's bnd who does the fieldwork in both cases, and not the > plugin itself. > > I feel bad for Quinn because he's worked on this, and I'm sure it wasn't an > easy task. > > Quinn, what are the benefits vs cons of adopting this plugin, from your > point of view? > > Cheers. > On 6 Apr 2016 7:49 a.m., "Achim Nierbeck" <bcanh...@googlemail.com> wrote: > >> Hi, >> >> just wanted to give my 2 cents here. >> I'm watching the bnd-maven-plugin for a while now, from my perspective it's >> not quite there yet, that's why I would stick with the maven-bundle-plugin >> for a while. >> >> regards, Achim >> >> >> 2016-04-06 7:46 GMT+02:00 Claus Ibsen <claus.ib...@gmail.com>: >> >>> Hi >>> >>> It all sound promising. But there is plenty of changes already for >>> 2.18 in the build system. We should IMHO keep this version as-is to >>> avoid too many changes. Building OSGi bundles is really complex for a >>> project the size as Apache Camel. We need to get what we have now out >>> to the community. >>> >>> Changing to a new plugin seems a bit risky to me at this stage. >>> >>> For the next release Camel 2.19 or what the version is, then it can be >>> on the roadmap and then other issues we discover such as what you >>> found that required a version 3.2.0 etc can be ironed out. >>> >>> >>> >>> >>> >>> >>> On Tue, Apr 5, 2016 at 8:58 PM, Quinn Stevenson >>> <qu...@pronoia-solutions.com> wrote: >>>> I’ve got the basics down for doing this conversion, but there are a >>> couple of differences between the MANIFEST.MF files generated by the two >>> tools when SNAPSHOT versions are used. >>>> >>>> Bundle-Version header: >>>> By default, given a version in a POM like "1.2.3-SNAPSHOT”: >>>> - the maven-bundle-plugin converts the version to “X.X.X.SNAPSHOT" >>>> - the bnd-maven-plugin changes the version "X.X.X.<timestamp>" >>>> There is a new instruction in the upcoming 3.2.0 release of the >>> bad-maven-plugin that will allow preserving the “.SNAPSHOT” in the >>> Bundle-Version header. >>>> >>>> I’m assuming we want to preserve the “.SNAPSHOT” in the Bundle-Version >>> header, so we’ll need to wait for version 3.2.0 of the bnd-maven-plugin >>>> >>>> Export-Package header: >>>> - the maven-bundle-plugin includes “.SNAPSHOT” in the version of >>> exported packages - i.e. org.apache.camel;version=“2.18.0-SNAPSHOT" >>>> - the bnd-maven-plugin does not include “.SNAPSHOT” in the version of >>> the exported packages - i.e. org.apache.camel;version=“2.18.0” >>>> The bad-maven-plugin can be configured to do this by adding a >>> “packageinfo” file for every exported package >>>> >>>> Do we need to keep the “.SNAPSHOT” in the exported package versions? >>>> >>>> >>> >>> >>> >>> -- >>> Claus Ibsen >>> ----------------- >>> http://davsclaus.com @davsclaus >>> Camel in Action 2: https://www.manning.com/ibsen2 >>> >> >> >> >> -- >> >> Apache Member >> Apache Karaf <http://karaf.apache.org/> Committer & PMC >> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & >> Project Lead >> blog <http://notizblog.nierbeck.de/> >> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >> >> Software Architect / Project Manager / Scrum Master >>
