camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: [DISCUSS] - Moving from maven-bundle-plugin to bnd-maven-plugin and SNAPSHOT versions
Date Tue, 05 Apr 2016 23:29:41 GMT
I don’t know how camel is doing release versions after a period of development, but recall
that osgi version 1.2.3.SNAPSHOT is after 1.2.3, so if you use normal maven release practices
and version the exported packages the same as the bundle version (a terrible idea, but IIUC
what you are doing), then a snapshot would be preferred over a release version as it appears
to be later.

david jencks

> On Apr 5, 2016, at 4:15 PM, Quinn Stevenson <> wrote:
> I did manage to get the bnd-maven-plugin to generate the Export-Package header as it
is today - with “.SNAPSHOT” on the version - but I had to add a packageinfo file to every
exported package (as described by the snippet posted below) - they had the same content, but
I had to put them there.  This could be a good thing long-term if we ever get to the point
of actually versioning the packages instead of just the entire bundle, but it’s a just lot
of duplication right now.
> I’m struggling with coming up with a way I’d actually use multiple SNAPSHOT versions
of the same module - I can’t think of where this would make any sense.  In fact, it happened
to me by accident when working with one client, and it was a huge problem/mess.  Further,
even if .SNAPSHOT is on the version of the exported package, what exactly does that accomplish?
 The versions of the exported packages for a given module would always be the same (i.e. they’d
always have the .SNAPSHOT at the end), so the only way to tell what version of which package
you’re using would be by the Bundle-Version anyway - and it doesn’t help either because
it’s listed as .SNAPSHOT.  The only way I could see actually using this to any effect would
be to use the bnd-maven-plugin default option of putting in a timestamp - that actually provides
something you can work with to distinguish bundles and package versions.
> So while I’m a little nervous changing the export package versioning scheme we use
(by dropping the .SNAPSHOT), it feels like the right thing to do in this case.
> As far as having access to the OSGi Version for the bundle - can you point me to a specific
example so I can figure out what I’d do there?
>> On Apr 5, 2016, at 4:15 PM, Raul Kripalani <> wrote:
>> On Tue, Apr 5, 2016 at 11:00 PM, Matt Pavlovich <> wrote:
>>> I was ruminating about this as well-- I agree its not exact; however, is
>>> there any real impact?  The bundle version is indicated by the SNAPSHOT.
>>> How would the package export having the .SNAPSHOT qualifier (which would
>>> not impact any wiring) have any undesirable impact?
>> Hmmm... To be frank, off the top of my head right now, I can't come up with
>> a scenario where one would want to run coexisting SNAPSHOT and FINAL
>> modules for the same version. But the fact that one doesn't come to mind
>> doesn't mean that it's ok to bypass semantic accuracy.
>> In fact, the bnd docs even recognise using qualifiers to designate build
>> specifiers in package exports. So right now it feels like a shortcoming/bug
>> of the bnd-maven-plugin.
>> If you now export the package (from any bundle that has the package on its
>>> class path), it will be properly versioned.
>>> bnd.bnd:
>>>   build = ${tstamp}
>>>   Export-Package: com.example.*
>>> The resulting manifest will look like:
>>> Manifest:
>>>   Export-Package: com.example; version=1.2.0.*v201010101010*
>> My conclusion is that changing our package export policy as a consequence
>> of a possible (temporary) bug in the bnd-maven-plugin doesn't seem a sound
>> approach IMHO.
>> My preference would be to open a bug upstream and send a PR to fix the
>> issue there.
>> Cheers,
>> *Raúl Kripalani*
>> PMC & Committer @ Apache Ignite, Apache Camel | Integration, Big Data and
>> Messaging Engineer
>> |
>> Blog:
>> <>
>> twitter: @raulvk <>

View raw message