If you're not doing service oriented programming but share implementation
classes than just let your packages follow the bundle version. Not much use
trying to be too detailed. This kind of versioning can best be done in the bnd
instructions for the maven plugin, you can use wildcards.
If you have well defined API packages that have no link to implementation so
they can be used (clients) and (implemented) then there is a rather simple
trick to simplify maintenance if you use the maven plugin. bnd (which is the
underlying engine) supports a file called packageinfo (no extension). In this
file you can place:
version 1.0.0
bnd will pickup this version for any exported package. So when you change an
API package you can easily locally modify it. Please follow the OSGi guidelines:
micro = bug fixes that do not influence implementer nor client
minor = changes that do not affect clients but affects implementers
major = changes that affect clients (and implicitly implementers).
Notice that almost any change in the API requires a minor bump but there can
also be changes in the documentation that affect implementers. So virtually any
change excpt a type fix is a minor bump.
The problem is that in the current mode there is no way to generate this. Even
if I had access to the last version, there are changes that influence the
version but they are binary compatible with for both implementers as well as
clients. Only the human making this change can reflect on this.
In reality, adding the versions the first time is hard. Working more service
oriented significantly minimizes the number of packages you have to share and
thus version management. Changing the packageinfo file for a change to an API
package is very little overhead because those changes require serious thinking
anyway.
That said, I've done a lot of thinking of verifying the package versions when a
jar is submitted to a new repo. At that moment I can compare the packages in
detail against the previous version and decide about backward compatibility and
see if the versions match this. However, this requires bnd to be able to talk
to the repo and get the last version. Not figured out yet out how do this in a
simple enough way. Most of the diff code is already in bnd ...
Kind regards,
Peter Kriens
On 6 mei 2010, at 02:22, David Jencks wrote:
> I've been trying to figure out some package versions for some geronimo code
> today and think that, given an existing bundle and its next version, it's
> pretty much beyond human capabilities to correctly determine the package
> versions for the new bundle. Certainly I don't think anyone trying to tie up
> the loose ends for a release is going to be able to do it correctly.
>
> Are there any tools available to help with this?
>
> I don't think that anyone can expect any correct package versions in bundles
> until this is well supported by tooling.
>
> Ideally I'd like the maven-bundle-plugin to have a goal to determine the
> package versions by analyzing the code differences between the current code
> and the previous released version of a bundle, and for the normal operation
> of the plugin to compare these correct versions with explicitly configured
> versions to make it obvious when you have unintentionally changed
> compatibility.
>
> thanks
> david jencks
>
