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 <ra...@apache.org> wrote:
>
> On Tue, Apr 5, 2016 at 11:00 PM, Matt Pavlovich <mattr...@gmail.com> 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*
>
>
> http://www.aqute.biz/Bnd/Versioning
>
> 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
> http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani
> Blog: raul.io
> <http://raul.io/?utm_source=email&utm_medium=email&utm_campaign=apache> |
> twitter: @raulvk <https://twitter.com/raulvk>
