It is not really much work.
When you do a release in maven you will change your maven version number
anyway. So this is something you will not do just for the baselining.
I explicitly set a comparisonVersion .. but I think if you leave this
out it defaults to the last release version. So maybe you do not have to
maintain this.
In almost all projects I use the same version in maven for the whole set
of projects ... the downside is that this means
that for any release you release all bundles in that set of projects. In
practice this is often good for users and does not affect OSGi
deployment in any way.
As you probably know the compatibility in OSGi is done per package. So
the bundle version does not matter much.
Versioning the whole set of projects makes releases a lot simpler and
also helps a lot when using git which is a pain if you version each
bundle separately.
Christian
On 22.06.2017 18:27, Tom Quarendon wrote:
I'm going to have to delve deeper into how this works.
It's all a *lot* more manual than I understood it to be, or hoped it would be.
I come back to bndtools.
As far as I know, literally all I do is change code. It gives me a build error
if I don't also change the version numbers in a suitable way.
That's it, nothing more to do. No manually changing version numbers in
preparation for release, or after release etc. Code that I don't change has the
same package and bundle version numbers, and that's fine, and indeed exactly
what I want I think.
If my prfelixocess has to include me remembering to go through some series of
steps each time, it kind of defeats the object for me.
I understood that baselining in bndtools at least promised to save me from
forgetting to update the package/bundle version numbers. It seems that isn't
the case in the same way using the maven plugin.
I'm going to have to do some experimentation I think, and maybe see if I can
achieve the same thing within a bndtools setup.
-----Original Message-----
From: Christian Schneider [mailto:cschneider...@gmail.com] On Behalf Of
Christian Schneider
Sent: 22 June 2017 17:07
To: Tom Quarendon <tom.quaren...@worldprogramming.com>
Subject: Re: API baselining with maven-bundle-plugin
See how we use the plugin is Aries rsa:
This is the plugin config:
https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L223-L247
The comparisonVersion is set to 1.9.0:
https://github.com/apache/aries-rsa/blob/master/parent/pom.xml#L28
Typically you set the baseline to the last release of your project. This means
changes in your current code are compared to the given version.
This is one package where we actually use baselining:
https://github.com/apache/aries-rsa/blob/master/spi/src/main/java/org/apache/aries/rsa/spi/packageinfo
When I now change an interface incompatibly in this package the baselining will
complain in the build. If I then increase the version in packageinfo to the the
next major version the build will accept incompatible changes.
Christian
On 22.06.2017 16:01, Tom Quarendon wrote:
I'm trying to set up api baselining using the maven-bundle-plugin.
I think I have it set up. I have messages coming out that say it's doing stuff.
So that's good.
Forgive my confusion though, but I don't understand how it is supposed to work.
I have published a 1.0.0 version of my bundle to the repository.
I then make an incompatible change to the API, I get:
Unable to find a previous version of the project in the repository
If I manually change the version number in my pom to 1.0.1, I then get errors
about my API having changed and it requiring a change in version number.
So I don't understand. I only get a baseline check once I've remembered to
change the version number? Surely the point is to tell me that I *need* to
change the version number? That's certainly the support you get in bndtools
(being also based on bnd, same as the maven plugin).
Have I set it up correctly? Or is this how it's supposed to work?
In the configuration, it looks like the setting comparisonVersion is initialised to
(,${project.version}) by default, presumably meaning "up to and not including
${project.version}".
Changing that to be (,${project.version}] makes it do a comparison, but
produces no errors, presumably because it's comparing the bundle against
itself. What I want it to do is compare against the current latest in the
release repository.
So I'm confused. How do I make it tell me that I need to change my project
version, without first changing my project version?
Thanks.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
