On 4/5/16 6:29 PM, David Jencks wrote:
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.
That's an important point-- the SNAPSHOT being favored over the release
(b/c it is presumed to be *more* current) would be bad mojo.
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>
