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 <qu...@pronoia-solutions.com>
> 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 <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>
>
