You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Tom Quarendon <to...@worldprogramming.com> on 2017/06/22 14:01:49 UTC
API baselining with maven-bundle-plugin
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.
Re: API baselining with maven-bundle-plugin
Posted by Christian Schneider <ch...@die-schneider.net>.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: API baselining with maven-bundle-plugin
Posted by Justin Edelson <ju...@justinedelson.com>.
I'm not going to try to convince you of the merits of the Maven release
convention. All I'll say is that either you acknowledge that releases are
immutable or you don't. And if you do, then there really are only a limited
number of ways to ensure this is done in a reliable, repeatable fashion.
On Thu, Jun 22, 2017 at 1:12 PM Tom Quarendon <
tom.quarendon@worldprogramming.com> wrote:
> The cadence is important I that if I want to "release" off the back of
> each build, I don't want to have to manually make a code modification every
> day, nor do I want to have the build process modify the source code, that
> just doesn't seem right.
>
> I'm probably at odds with standard practice.
>
> -----Original Message-----
> From: Justin Edelson [mailto:justin@justinedelson.com]
> Sent: 22 June 2017 17:40
> To: users@felix.apache.org
> Subject: Re: API baselining with maven-bundle-plugin
>
> The cadence of releases is irrelevant. But each release must have a
> distinct (bundle) version number. Otherwise, the version loses any meaning
> since two copies of "version 1.0.0" are not necessarily the same.
>
> If you only want to change the bundle version when you start changing the
> project, that's certainly a choice you can make. I find (and many others do
> too) it easier to do this automatically at the time of release (i.e. set
> the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't get
> forgotten.
>
> I can't speak to how bndtools work. I assume it must do some kind of
> automatic bundle version management since it would be inappropriate to have
> mutable releases.
>
>
> On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
> tom.quarendon@worldprogramming.com> wrote:
>
> > I perhaps have a different concept of how things work. But I'm not
> > very familiar with how maven works.
> >
> > Fundamentally, if I haven't changed any code, why have any of the
> > version numbers changed? I'm perhaps viewing things from a continuous
> > deployment perspective rather than a "release once a year" perspective.
> >
> > As far as I can tell with bndtools, version numbers are changed as,
> > and only as necessary.
> > I check out the source code, and then as I change code, it prompts me
> > to change package and bundle versions appropriately.
> > Hence after my edits, the package and version numbers of things I
> > haven't changed are the same as they were, which seems right to me.
> > Things that I've changed have changed version package and bundle version
> numbers.
> > If I then do a "mvn deploy" (well, "gradle release") on the result,
> > then OK, the unchanged bundles will be re-released to the repository
> > (or maybe not, maybe maven/gradle doesn't replace a bundle with one
> > with the same version, don't know), but the contents are the same
> > (from a source perspective anyhow), so that doesn't matter.
> >
> > As I say, I don't have much experience of using maven etc, I was
> > confused that it worked in an apparently different way to bndtools,
> > which is based on the same thing.
> >
> >
> >
> > -----Original Message-----
> > From: Justin Edelson [mailto:justin@justinedelson.com]
> > Sent: 22 June 2017 15:15
> > To: users@felix.apache.org
> > Subject: Re: API baselining with maven-bundle-plugin
> >
> > Hi,
> > I think you might be mixing up the bundle version (what I think you
> > are referring to as the "project version") with the package versions.
> > baseline is larger concerned with the latter, and only uses the former
> > to find the comparison version.
> >
> > Released versions should always be considered immutable, so you should
> > *always* change the project version immediately after a release. If
> > you use the maven-release-plugin, this is automatically done, but
> > otherwise you would need to do this manually.
> >
> > Here's the way it is supposed to work:
> >
> > * You have a bundle with version 1.0.0 and package com.myco.foo at
> > version 1.0.0. This bundle is deployed in some repository.
> > * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> > 1.0.1-SNAPSHOT in Maven terms).
> > * You make some change to one of the classes/interfaces in com.myco.foo.
> > * Then you run the baseline plugin. Baseline compares the current
> > state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
> > checks each exported package. It sees that there has been some change
> > in com.myco.foo which requires that the package version change. It
> > then alerts you to this change and recommends a new package version
> > number. Alternatively, if you changed the exported package version,
> > baseline will still tell you that there was a change made but that you
> > have already correctly changed the package version number.
> >
> > HTH,
> > Justin
> >
> > On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> > tom.quarendon@worldprogramming.com> 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.
> > >
> >
>
Re: API baselining with maven-bundle-plugin
Posted by Christian Schneider <ch...@die-schneider.net>.
>
>
> It's the difference between:
> "I'm trying to build something that the user wants to call 1.0.0. As
> part of that process I'll check whether it conflicts with what is currently
> 1.0.0, and if it does I'll fail, not actually creating the artefact at all,
> and suggest that they change the version numbers appropriately."
>
In maven you always build snapshots unless doing a full release. If you use
a non SNAPSHOT version in the code on master then you are doing it wrong.
So what you say in maven terms is I build 1.0.0-SNAPSHOT and want it to
fail if it conflicts with the current 1.0.0-SNAPSHOT. This is inherently
fragile as the current snapshot is transient and might even be different
between developers.
So it is much better to compare the current code with the last release and
fail if it is incompatible. This is exactly what the baselining does. After
the fail you then once increase the package version and get your build
working again. Future changes in this package will then not fail the build
until you do a release which moves the baseline again.
Christian
Open Source Architect
http://www.talend.com
<https://owa.talend.com/owa/redir.aspx?C=3aa4083e0c744ae1ba52bd062c5a7e46&URL=http%3a%2f%2fwww.talend.com>
Re: API baselining with maven-bundle-plugin
Posted by Christian Schneider <ch...@die-schneider.net>.
Ok.. now this makes more sense to me :-)
See here for how to block overwriting of artifacts.
https://stackoverflow.com/questions/6461152/how-can-i-prevent-previously-deployed-artifacts-from-being-overwritten
Christian
On 27.06.2017 09:28, Tom Quarendon wrote:
> I'm not *wanting* to allow overwriting release versions, that is kind of the point.
> But, out of the box, an artifactory maven (release) repository appears to allow this. And there's no configuration option that I can find that says "don't allow overwriting versions".
>
> It's not obvious to me, not having that much experience with maven, whether this is "right" or "wrong". I *think* that the maven view of the world is that there is one, unique, artefact with any given (non-snapshot) version number, and therefore that any two artifacts that you might see with the same (non-snapshot) coordinates are to be considered equivalent. The corollary of that is that versions are (should be) immutable. But if that is the case, then artifactory breaks that rule by allowing you to overwrite released versions.
> As I say, my understanding of maven is shallow.
>
> Relying on uniqueness of git tags seems like the most profitable route, assuming I can understand how I ensure that that check is done before the upload actually happens.
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: API baselining with maven-bundle-plugin
Posted by Tom Quarendon <to...@worldprogramming.com>.
I'm not *wanting* to allow overwriting release versions, that is kind of the point.
But, out of the box, an artifactory maven (release) repository appears to allow this. And there's no configuration option that I can find that says "don't allow overwriting versions".
It's not obvious to me, not having that much experience with maven, whether this is "right" or "wrong". I *think* that the maven view of the world is that there is one, unique, artefact with any given (non-snapshot) version number, and therefore that any two artifacts that you might see with the same (non-snapshot) coordinates are to be considered equivalent. The corollary of that is that versions are (should be) immutable. But if that is the case, then artifactory breaks that rule by allowing you to overwrite released versions.
As I say, my understanding of maven is shallow.
Relying on uniqueness of git tags seems like the most profitable route, assuming I can understand how I ensure that that check is done before the upload actually happens.
-----Original Message-----
From: Christian Schneider [mailto:cschneider111@gmail.com] On Behalf Of Christian Schneider
Sent: 27 June 2017 08:21
To: Tom Quarendon <to...@worldprogramming.com>; users@felix.apache.org
Subject: Re: API baselining with maven-bundle-plugin
Be very careful with overwriting a release version. It is easy to configure a maven repository like artifactory to allow that but you will have problems in other places.
The crucial problem is with the local maven repo. Maven updates snapshots in a configurable way but it never updates release versions.
So if maven downloaded a 1.0.0 version of an artifact once it will never overwrite it again or even check if there is a new version.
So if you want to use continuous deployment then you either need to use snapshots .. which makes the releases not really reproducible or you need to use an automatic release process that simply increases a version and does the full release process.
Christian
On 27.06.2017 09:05, Tom Quarendon wrote:
>> 2. If you have released version 1.0.0. (i.e. non-SNAPSHOT) of a bundle with Maven then you will be able to build another 1.0.0 locally, but you will not be able to release it again — this is a built-in feature of Maven. At this point you will be forced to bump your bundle version, so it is slightly less powerful than bnd baselining which will not even permit you to build locally bundle 1.0.0 if it has a delta against the released bundle.
> This isn't my experience. I appear to be able to happily re-release bundles of the same version number into artifactory using maven.
> I have a bundle:
>
> Created: 22-06-17 14:14:59 +01:00
> Last Modified: 27-06-17 07:59:48 +01:00
>
> This is kind of the point really.
> Maybe I can configure artifactory to prevent that, but not obviously.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: API baselining with maven-bundle-plugin
Posted by Christian Schneider <ch...@die-schneider.net>.
Be very careful with overwriting a release version. It is easy to
configure a maven repository like artifactory to allow that but you will
have problems in other places.
The crucial problem is with the local maven repo. Maven updates
snapshots in a configurable way but it never updates release versions.
So if maven downloaded a 1.0.0 version of an artifact once it will never
overwrite it again or even check if there is a new version.
So if you want to use continuous deployment then you either need to use
snapshots .. which makes the releases not really reproducible or you
need to use an automatic release process that simply increases a version
and does the full release process.
Christian
On 27.06.2017 09:05, Tom Quarendon wrote:
>> 2. If you have released version 1.0.0. (i.e. non-SNAPSHOT) of a bundle with Maven then you will be able to build another 1.0.0 locally, but you will not be able to release it again — this is a built-in feature of Maven. At this point you will be forced to bump your bundle version, so it is slightly less powerful than bnd baselining which will not even permit you to build locally bundle 1.0.0 if it has a delta against the released bundle.
> This isn't my experience. I appear to be able to happily re-release bundles of the same version number into artifactory using maven.
> I have a bundle:
>
> Created: 22-06-17 14:14:59 +01:00
> Last Modified: 27-06-17 07:59:48 +01:00
>
> This is kind of the point really.
> Maybe I can configure artifactory to prevent that, but not obviously.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
http://www.talend.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: API baselining with maven-bundle-plugin
Posted by Tom Quarendon <to...@worldprogramming.com>.
> 2. If you have released version 1.0.0. (i.e. non-SNAPSHOT) of a bundle with Maven then you will be able to build another 1.0.0 locally, but you will not be able to release it again — this is a built-in feature of Maven. At this point you will be forced to bump your bundle version, so it is slightly less powerful than bnd baselining which will not even permit you to build locally bundle 1.0.0 if it has a delta against the released bundle.
This isn't my experience. I appear to be able to happily re-release bundles of the same version number into artifactory using maven.
I have a bundle:
Created: 22-06-17 14:14:59 +01:00
Last Modified: 27-06-17 07:59:48 +01:00
This is kind of the point really.
Maybe I can configure artifactory to prevent that, but not obviously.
RE: API baselining with maven-bundle-plugin
Posted by Tom Quarendon <to...@worldprogramming.com>.
So, just to flesh that out a bit.
Bearing in mind I know very little about maven:
I use the maven scm plugin to tag the git repository a part of the "deploy" phase. I make the tag name based on the project name and version number. This process will then fail if there is already tag of the same name in the git repository. That sounds good. This gives me an alternative means of ensuring that there is only one thing called "myproject-1.0.0"
How do I ensure though that that fails before it then attempts to upload to the repository? This is where my lack of understanding of maven and its operating model comes in. I want it do this as part of me running "mvn deploy", but I need it to happen *first*, before the upload. Otherwise all I have is a "oh, by the way, the thing you just uploaded? That just overwrote something..."
-----Original Message-----
From: James Carman [mailto:james@carmanconsulting.com]
Sent: 23 June 2017 19:04
To: users@felix.apache.org
Subject: Re: API baselining with maven-bundle-plugin
Presumably, you'd also have your SCM system standing watch. You shouldn't be able to recreate tags, for instance, and any good release process should include tagging of your released artifacts. Obviously, someone can delete tags, but that should be frowned upon.
On Fri, Jun 23, 2017 at 1:54 PM Milen Dyankov <mi...@gmail.com>
wrote:
> >
> > you will be able to build another 1.0.0 locally, but you will not be
> > able to release it again
>
>
> I think that depends on particular Maven repository and it's configuration.
> While this is probably true for Central (not sure but would assume so)
> a local Nexus repo can be configured to allow re-releasing.
>
> On Fri, Jun 23, 2017 at 7:30 PM, Neil Bartlett <nj...@gmail.com>
> wrote:
>
> > Hi Tom,
> >
> > I’m very glad that you’re enjoying the baselining feature of
> > Bndtools so much!
> >
> > I think your expectations are reasonable but we just aren’t quite
> > there with bnd/Maven integration.
> >
> > Bndtools is able to give you immediate baselining errors, but it
> currently
> > only works when bndlib is called directly by Bndtools. In a Maven
> workspace
> > using M2Eclipse, the bundle is built by maven-bundle-plugin or
> > bnd-maven-plugin, which of course use bndlib internally, but
> > Bndtools is isolated from it by a layer of Maven. The
> > bnd-maven-plugin is run incrementally by M2E but we don’t yet have a
> > way to catch the baselining errors from bnd-maven-plugin and report
> > them in the IDE. In the future we
> > *may* be able to do this, I’m not sure.
> >
> > So, you won’t get immediate feedback on versioning errors but I
> > would still expect the build to be affected as follows:
> >
> > 1. Package versions will be checked and will fail the build when
> > they are incorrect. This is a feature of bnd surfaced through the
> bnd-maven-plugin.
> >
> > 2. If you have released version 1.0.0. (i.e. non-SNAPSHOT) of a
> > bundle with Maven then you will be able to build another 1.0.0
> > locally, but you will not be able to release it again — this is a
> > built-in feature of
> Maven.
> > At this point you will be forced to bump your bundle version, so it
> > is slightly less powerful than bnd baselining which will not even
> > permit you to build locally bundle 1.0.0 if it has a delta against
> > the released
> bundle.
> >
> > Still, you don’t have to *remember* to bump your versions, the build
> > tool will force you to do it eventually.
> >
> > If a Maven developer would like to check and correct my
> > understanding — particularly on point 2 above — please do so!
> >
> > Thanks,
> > Neil
> >
> >
> >
> > > On 23 Jun 2017, at 14:26, Tom Quarendon <tom.quarendon@
> > worldprogramming.com> wrote:
> > >
> > > So here's what I've just done in bndtools.
> > >
> > > Created a project that has three bundles in it, test.api,
> > > test.command,
> > test.provider. All versions (package, bundle) are initialised to 1.0.0.
> > > Set up the project so that it will release to a maven repository.
> > > Run the "gradle release" command line option.
> > > I now have a "1.0.0" version of the bundle in my maven repository.
> > > Set up baselining. This requires nothing more than adding:
> > > "-baseline:*"
> > > To my build.bnd configuration file. I don't have to say "baseline
> > against version X" etc and keep that up to date.
> > >
> > > Then, literally ALL I did was change the method signature on one
> > > of the
> > methods.
> > > I get, immediately, errors such as:
> > > The method 'say(java.lang.String)' was removed, which requires a
> > > MAJOR
> > change to the package.
> > > versioning.test.api: The bundle version (1.0.0/1.0.0) is too low,
> > > must
> > be at least 2.0.0
> > >
> > > I resolve all of the issues and I now have my package and bundle
> version
> > numbers at 2.0.0, which is what they need to be given the change in
> > the source code.
> > > I get the same errors if I run the gradle build that bndtools
> > > produces
> > for you.
> > >
> > > Note, I didn't first bump the versions, then make the code change.
> > > ALL
> I
> > did was make the code change.
> > >
> > > So I don't think what I'm trying to do is unreasonable. I don't
> > > have to
> > remember to bump any versions, I get build failures unless I do. Perfect.
> > >
> > > This is what I'm trying to replicate, but in a project that wasn't
> > originally written with bndtools. I thought maven might be a simpler
> route
> > as it's used elsewhere, and I naively thought I might be able to do
> > it using the bnd plugin for maven, since it exposes the baseline facility.
> > >
> > > Clearly I can't. Clearly my world view doesn't align with maven's.
> > That's fine.
> > >
> > > I will refocus my efforts on trying to do the same thing in
> > > gradle,
> > where I think I will have more success.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Justin Edelson [mailto:justin@justinedelson.com]
> > > Sent: 23 June 2017 14:00
> > > To: users@felix.apache.org
> > > Subject: Re: API baselining with maven-bundle-plugin
> > >
> > > On Fri, Jun 23, 2017 at 3:23 AM Tom Quarendon < tom.quarendon@
> > worldprogramming.com> wrote:
> > >
> > >> I get immutable releases. I'm not trying to redefine what 1.0.0
> > >> is with different source code. In fact quite the opposite. I want
> > >> it to *prevent me from doing do*. The maven bnd plugin doesn't
> > >>
> > >> It's the difference between:
> > >> "I'm trying to build something that the user wants to call
> > >> 1.0.0. As part of that process I'll check whether it conflicts
> > >> with what is currently 1.0.0, and if it does I'll fail, not
> > >> actually creating the artefact at all, and suggest that they
> > >> change the version numbers
> > appropriately."
> > >>
> > >
> > > If there is already something called "1.0.0", the user shouldn't
> > > be
> > building something else called "1.0.0". But the detection of that
> > isn't
> the
> > job of the bundle plugin's baseline goal which is solely concerned
> > with package versions, not bundle/project versions. What you are
> > talking about here is, as I've written previously, typically handled
> > by the release process and, as David wrong, enforced at the
> > repository. It would violate the SRP for the bundle plugin to get
> > involved with this, especially since this problem has absolutely nothing to do with OSGi.
> > >
> > > Regards,
> > > Justin
> > >
> > >
> > >
> > >
> > >> And
> > >> "I'm building something that the user wants to call 1.0.0. Once
> > >> I've done that, I'll take that and compare it with another
> > >> version to see whether the difference in version numbers, what
> > >> the user has done to change the version numbers between those two
> > >> versions, is consistent with any changes in the source code, and
> > >> if not complain. The build artefact however will now exist".
> > >>
> > >> I want the former. The maven bnd plugin appears to implement the
> latter.
> > >> As far as I understand, bndtools implements the former, I *can*
> > >> implement the former with bnd. It doesn't appear possible to
> > >> implement the former with maven due to the way it works.
> > >
> > >
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Neil Bartlett [mailto:njbartlett@gmail.com]
> > >> Sent: 22 June 2017 18:52
> > >> To: users@felix.apache.org
> > >> Subject: Re: API baselining with maven-bundle-plugin
> > >>
> > >> Are you sure that you’re actually *releasing* every day? Or do
> > >> you only mean sending out snapshots?
> > >>
> > >> I agree with Justin that releases should be immutable, and that
> > >> is what bnd and Bndtools have always tried to achieve. However
> > >> bnd is not a complete end-to-end build system like Maven or
> > >> Gradle, and Bndtools is only an IDE, so we don’t get a lot of say in the larger process.
> > >> You should work within the conventions of whatever build tool you use.
> > >>
> > >> The process encouraged by bnd is very close to the Maven one.
> > >> Once a release is made, you must not change it. If you change a
> > >> package after a release, then you move up to a new version number for that package.
> > >> You can then build and publish as many snapshot of that new
> > >> version number as you like, usually with a timestamp in the
> > >> qualifier segment
> > of the version.
> > >> Once you release, that version is consumed and you go back to the
> > >> beginning of this paragraph.
> > >>
> > >> Neil
> > >>
> > >>
> > >>> On 22 Jun 2017, at 18:12, Tom Quarendon <
> > >> tom.quarendon@worldprogramming.com> wrote:
> > >>>
> > >>> The cadence is important I that if I want to "release" off the
> > >>> back of
> > >> each build, I don't want to have to manually make a code
> > >> modification every day, nor do I want to have the build process
> > >> modify the source code, that just doesn't seem right.
> > >>>
> > >>> I'm probably at odds with standard practice.
> > >>>
> > >>> -----Original Message-----
> > >>> From: Justin Edelson [mailto:justin@justinedelson.com]
> > >>> Sent: 22 June 2017 17:40
> > >>> To: users@felix.apache.org
> > >>> Subject: Re: API baselining with maven-bundle-plugin
> > >>>
> > >>> The cadence of releases is irrelevant. But each release must
> > >>> have a
> > >> distinct (bundle) version number. Otherwise, the version loses
> > >> any meaning since two copies of "version 1.0.0" are not
> > >> necessarily the
> > same.
> > >>>
> > >>> If you only want to change the bundle version when you start
> > >>> changing the project, that's certainly a choice you can make. I
> > >>> find (and many others do
> > >>> too) it easier to do this automatically at the time of release (i.e.
> > >>> set
> > >> the master/trunk version to lastversion+1-SNAPSHOT) so that it
> > >> doesn't get forgotten.
> > >>>
> > >>> I can't speak to how bndtools work. I assume it must do some
> > >>> kind of
> > >> automatic bundle version management since it would be
> > >> inappropriate to have mutable releases.
> > >>>
> > >>>
> > >>> On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
> > >> tom.quarendon@worldprogramming.com> wrote:
> > >>>
> > >>>> I perhaps have a different concept of how things work. But I'm
> > >>>> not very familiar with how maven works.
> > >>>>
> > >>>> Fundamentally, if I haven't changed any code, why have any of
> > >>>> the version numbers changed? I'm perhaps viewing things from a
> > >>>> continuous deployment perspective rather than a "release once a
> year"
> > perspective.
> > >>>>
> > >>>> As far as I can tell with bndtools, version numbers are changed
> > >>>> as, and only as necessary.
> > >>>> I check out the source code, and then as I change code, it
> > >>>> prompts me to change package and bundle versions appropriately.
> > >>>> Hence after my edits, the package and version numbers of things
> > >>>> I haven't changed are the same as they were, which seems right to me.
> > >>>> Things that I've changed have changed version package and
> > >>>> bundle
> > >> version numbers.
> > >>>> If I then do a "mvn deploy" (well, "gradle release") on the
> > >>>> result, then OK, the unchanged bundles will be re-released to
> > >>>> the repository (or maybe not, maybe maven/gradle doesn't
> > >>>> replace a bundle with one with the same version, don't know),
> > >>>> but the contents are the same (from a source perspective
> > >>>> anyhow), so that
> > doesn't matter.
> > >>>>
> > >>>> As I say, I don't have much experience of using maven etc, I
> > >>>> was confused that it worked in an apparently different way to
> > >>>> bndtools, which is based on the same thing.
> > >>>>
> > >>>>
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Justin Edelson [mailto:justin@justinedelson.com]
> > >>>> Sent: 22 June 2017 15:15
> > >>>> To: users@felix.apache.org
> > >>>> Subject: Re: API baselining with maven-bundle-plugin
> > >>>>
> > >>>> Hi,
> > >>>> I think you might be mixing up the bundle version (what I think
> > >>>> you are referring to as the "project version") with the package
> versions.
> > >>>> baseline is larger concerned with the latter, and only uses the
> > >>>> former to find the comparison version.
> > >>>>
> > >>>> Released versions should always be considered immutable, so you
> > >>>> should
> > >>>> *always* change the project version immediately after a
> > >>>> release. If you use the maven-release-plugin, this is
> > >>>> automatically done, but otherwise you would need to do this manually.
> > >>>>
> > >>>> Here's the way it is supposed to work:
> > >>>>
> > >>>> * You have a bundle with version 1.0.0 and package com.myco.foo
> > >>>> at version 1.0.0. This bundle is deployed in some repository.
> > >>>> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> > >>>> 1.0.1-SNAPSHOT in Maven terms).
> > >>>> * You make some change to one of the classes/interfaces in
> > com.myco.foo.
> > >>>> * Then you run the baseline plugin. Baseline compares the
> > >>>> current state against the last release (so 1.0.1.SNAPSHOT vs.
> > >>>> 1.0.0) and checks each exported package. It sees that there has
> > >>>> been some change in com.myco.foo which requires that the
> > >>>> package version change. It then alerts you to this change and
> > >>>> recommends a new package version number. Alternatively, if you
> > >>>> changed the exported package version, baseline will still tell
> > >>>> you that there was a change made but that you have already
> > >>>> correctly changed the package
> > version number.
> > >>>>
> > >>>> HTH,
> > >>>> Justin
> > >>>>
> > >>>> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> > >>>> tom.quarendon@worldprogramming.com> 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.
> > >>>>>
> > >>>>
> > >>>
> > >>> ----------------------------------------------------------------
> > >>> ----
> > >>> - To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >>> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >> -----------------------------------------------------------------
> > >> ---- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >
> > > ------------------------------------------------------------------
> > > --- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
> --
> http://about.me/milen
>
Re: API baselining with maven-bundle-plugin
Posted by James Carman <ja...@carmanconsulting.com>.
Presumably, you'd also have your SCM system standing watch. You shouldn't
be able to recreate tags, for instance, and any good release process should
include tagging of your released artifacts. Obviously, someone can delete
tags, but that should be frowned upon.
On Fri, Jun 23, 2017 at 1:54 PM Milen Dyankov <mi...@gmail.com>
wrote:
> >
> > you will be able to build another 1.0.0 locally, but you will not be able
> > to release it again
>
>
> I think that depends on particular Maven repository and it's configuration.
> While this is probably true for Central (not sure but would assume so) a
> local Nexus repo can be configured to allow re-releasing.
>
> On Fri, Jun 23, 2017 at 7:30 PM, Neil Bartlett <nj...@gmail.com>
> wrote:
>
> > Hi Tom,
> >
> > I’m very glad that you’re enjoying the baselining feature of Bndtools so
> > much!
> >
> > I think your expectations are reasonable but we just aren’t quite there
> > with bnd/Maven integration.
> >
> > Bndtools is able to give you immediate baselining errors, but it
> currently
> > only works when bndlib is called directly by Bndtools. In a Maven
> workspace
> > using M2Eclipse, the bundle is built by maven-bundle-plugin or
> > bnd-maven-plugin, which of course use bndlib internally, but Bndtools is
> > isolated from it by a layer of Maven. The bnd-maven-plugin is run
> > incrementally by M2E but we don’t yet have a way to catch the baselining
> > errors from bnd-maven-plugin and report them in the IDE. In the future we
> > *may* be able to do this, I’m not sure.
> >
> > So, you won’t get immediate feedback on versioning errors but I would
> > still expect the build to be affected as follows:
> >
> > 1. Package versions will be checked and will fail the build when they are
> > incorrect. This is a feature of bnd surfaced through the
> bnd-maven-plugin.
> >
> > 2. If you have released version 1.0.0. (i.e. non-SNAPSHOT) of a bundle
> > with Maven then you will be able to build another 1.0.0 locally, but you
> > will not be able to release it again — this is a built-in feature of
> Maven.
> > At this point you will be forced to bump your bundle version, so it is
> > slightly less powerful than bnd baselining which will not even permit you
> > to build locally bundle 1.0.0 if it has a delta against the released
> bundle.
> >
> > Still, you don’t have to *remember* to bump your versions, the build tool
> > will force you to do it eventually.
> >
> > If a Maven developer would like to check and correct my understanding —
> > particularly on point 2 above — please do so!
> >
> > Thanks,
> > Neil
> >
> >
> >
> > > On 23 Jun 2017, at 14:26, Tom Quarendon <tom.quarendon@
> > worldprogramming.com> wrote:
> > >
> > > So here's what I've just done in bndtools.
> > >
> > > Created a project that has three bundles in it, test.api, test.command,
> > test.provider. All versions (package, bundle) are initialised to 1.0.0.
> > > Set up the project so that it will release to a maven repository.
> > > Run the "gradle release" command line option.
> > > I now have a "1.0.0" version of the bundle in my maven repository.
> > > Set up baselining. This requires nothing more than adding:
> > > "-baseline:*"
> > > To my build.bnd configuration file. I don't have to say "baseline
> > against version X" etc and keep that up to date.
> > >
> > > Then, literally ALL I did was change the method signature on one of the
> > methods.
> > > I get, immediately, errors such as:
> > > The method 'say(java.lang.String)' was removed, which requires a MAJOR
> > change to the package.
> > > versioning.test.api: The bundle version (1.0.0/1.0.0) is too low, must
> > be at least 2.0.0
> > >
> > > I resolve all of the issues and I now have my package and bundle
> version
> > numbers at 2.0.0, which is what they need to be given the change in the
> > source code.
> > > I get the same errors if I run the gradle build that bndtools produces
> > for you.
> > >
> > > Note, I didn't first bump the versions, then make the code change. ALL
> I
> > did was make the code change.
> > >
> > > So I don't think what I'm trying to do is unreasonable. I don't have to
> > remember to bump any versions, I get build failures unless I do. Perfect.
> > >
> > > This is what I'm trying to replicate, but in a project that wasn't
> > originally written with bndtools. I thought maven might be a simpler
> route
> > as it's used elsewhere, and I naively thought I might be able to do it
> > using the bnd plugin for maven, since it exposes the baseline facility.
> > >
> > > Clearly I can't. Clearly my world view doesn't align with maven's.
> > That's fine.
> > >
> > > I will refocus my efforts on trying to do the same thing in gradle,
> > where I think I will have more success.
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Justin Edelson [mailto:justin@justinedelson.com]
> > > Sent: 23 June 2017 14:00
> > > To: users@felix.apache.org
> > > Subject: Re: API baselining with maven-bundle-plugin
> > >
> > > On Fri, Jun 23, 2017 at 3:23 AM Tom Quarendon < tom.quarendon@
> > worldprogramming.com> wrote:
> > >
> > >> I get immutable releases. I'm not trying to redefine what 1.0.0 is
> > >> with different source code. In fact quite the opposite. I want it to
> > >> *prevent me from doing do*. The maven bnd plugin doesn't
> > >>
> > >> It's the difference between:
> > >> "I'm trying to build something that the user wants to call 1.0.0. As
> > >> part of that process I'll check whether it conflicts with what is
> > >> currently 1.0.0, and if it does I'll fail, not actually creating the
> > >> artefact at all, and suggest that they change the version numbers
> > appropriately."
> > >>
> > >
> > > If there is already something called "1.0.0", the user shouldn't be
> > building something else called "1.0.0". But the detection of that isn't
> the
> > job of the bundle plugin's baseline goal which is solely concerned with
> > package versions, not bundle/project versions. What you are talking about
> > here is, as I've written previously, typically handled by the release
> > process and, as David wrong, enforced at the repository. It would violate
> > the SRP for the bundle plugin to get involved with this, especially since
> > this problem has absolutely nothing to do with OSGi.
> > >
> > > Regards,
> > > Justin
> > >
> > >
> > >
> > >
> > >> And
> > >> "I'm building something that the user wants to call 1.0.0. Once I've
> > >> done that, I'll take that and compare it with another version to see
> > >> whether the difference in version numbers, what the user has done to
> > >> change the version numbers between those two versions, is consistent
> > >> with any changes in the source code, and if not complain. The build
> > >> artefact however will now exist".
> > >>
> > >> I want the former. The maven bnd plugin appears to implement the
> latter.
> > >> As far as I understand, bndtools implements the former, I *can*
> > >> implement the former with bnd. It doesn't appear possible to implement
> > >> the former with maven due to the way it works.
> > >
> > >
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Neil Bartlett [mailto:njbartlett@gmail.com]
> > >> Sent: 22 June 2017 18:52
> > >> To: users@felix.apache.org
> > >> Subject: Re: API baselining with maven-bundle-plugin
> > >>
> > >> Are you sure that you’re actually *releasing* every day? Or do you
> > >> only mean sending out snapshots?
> > >>
> > >> I agree with Justin that releases should be immutable, and that is
> > >> what bnd and Bndtools have always tried to achieve. However bnd is not
> > >> a complete end-to-end build system like Maven or Gradle, and Bndtools
> > >> is only an IDE, so we don’t get a lot of say in the larger process.
> > >> You should work within the conventions of whatever build tool you use.
> > >>
> > >> The process encouraged by bnd is very close to the Maven one. Once a
> > >> release is made, you must not change it. If you change a package after
> > >> a release, then you move up to a new version number for that package.
> > >> You can then build and publish as many snapshot of that new version
> > >> number as you like, usually with a timestamp in the qualifier segment
> > of the version.
> > >> Once you release, that version is consumed and you go back to the
> > >> beginning of this paragraph.
> > >>
> > >> Neil
> > >>
> > >>
> > >>> On 22 Jun 2017, at 18:12, Tom Quarendon <
> > >> tom.quarendon@worldprogramming.com> wrote:
> > >>>
> > >>> The cadence is important I that if I want to "release" off the back
> > >>> of
> > >> each build, I don't want to have to manually make a code modification
> > >> every day, nor do I want to have the build process modify the source
> > >> code, that just doesn't seem right.
> > >>>
> > >>> I'm probably at odds with standard practice.
> > >>>
> > >>> -----Original Message-----
> > >>> From: Justin Edelson [mailto:justin@justinedelson.com]
> > >>> Sent: 22 June 2017 17:40
> > >>> To: users@felix.apache.org
> > >>> Subject: Re: API baselining with maven-bundle-plugin
> > >>>
> > >>> The cadence of releases is irrelevant. But each release must have a
> > >> distinct (bundle) version number. Otherwise, the version loses any
> > >> meaning since two copies of "version 1.0.0" are not necessarily the
> > same.
> > >>>
> > >>> If you only want to change the bundle version when you start
> > >>> changing the project, that's certainly a choice you can make. I find
> > >>> (and many others do
> > >>> too) it easier to do this automatically at the time of release (i.e.
> > >>> set
> > >> the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't
> > >> get forgotten.
> > >>>
> > >>> I can't speak to how bndtools work. I assume it must do some kind of
> > >> automatic bundle version management since it would be inappropriate to
> > >> have mutable releases.
> > >>>
> > >>>
> > >>> On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
> > >> tom.quarendon@worldprogramming.com> wrote:
> > >>>
> > >>>> I perhaps have a different concept of how things work. But I'm not
> > >>>> very familiar with how maven works.
> > >>>>
> > >>>> Fundamentally, if I haven't changed any code, why have any of the
> > >>>> version numbers changed? I'm perhaps viewing things from a
> > >>>> continuous deployment perspective rather than a "release once a
> year"
> > perspective.
> > >>>>
> > >>>> As far as I can tell with bndtools, version numbers are changed as,
> > >>>> and only as necessary.
> > >>>> I check out the source code, and then as I change code, it prompts
> > >>>> me to change package and bundle versions appropriately.
> > >>>> Hence after my edits, the package and version numbers of things I
> > >>>> haven't changed are the same as they were, which seems right to me.
> > >>>> Things that I've changed have changed version package and bundle
> > >> version numbers.
> > >>>> If I then do a "mvn deploy" (well, "gradle release") on the result,
> > >>>> then OK, the unchanged bundles will be re-released to the
> > >>>> repository (or maybe not, maybe maven/gradle doesn't replace a
> > >>>> bundle with one with the same version, don't know), but the
> > >>>> contents are the same (from a source perspective anyhow), so that
> > doesn't matter.
> > >>>>
> > >>>> As I say, I don't have much experience of using maven etc, I was
> > >>>> confused that it worked in an apparently different way to bndtools,
> > >>>> which is based on the same thing.
> > >>>>
> > >>>>
> > >>>>
> > >>>> -----Original Message-----
> > >>>> From: Justin Edelson [mailto:justin@justinedelson.com]
> > >>>> Sent: 22 June 2017 15:15
> > >>>> To: users@felix.apache.org
> > >>>> Subject: Re: API baselining with maven-bundle-plugin
> > >>>>
> > >>>> Hi,
> > >>>> I think you might be mixing up the bundle version (what I think you
> > >>>> are referring to as the "project version") with the package
> versions.
> > >>>> baseline is larger concerned with the latter, and only uses the
> > >>>> former to find the comparison version.
> > >>>>
> > >>>> Released versions should always be considered immutable, so you
> > >>>> should
> > >>>> *always* change the project version immediately after a release. If
> > >>>> you use the maven-release-plugin, this is automatically done, but
> > >>>> otherwise you would need to do this manually.
> > >>>>
> > >>>> Here's the way it is supposed to work:
> > >>>>
> > >>>> * You have a bundle with version 1.0.0 and package com.myco.foo at
> > >>>> version 1.0.0. This bundle is deployed in some repository.
> > >>>> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> > >>>> 1.0.1-SNAPSHOT in Maven terms).
> > >>>> * You make some change to one of the classes/interfaces in
> > com.myco.foo.
> > >>>> * Then you run the baseline plugin. Baseline compares the current
> > >>>> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
> > >>>> checks each exported package. It sees that there has been some
> > >>>> change in com.myco.foo which requires that the package version
> > >>>> change. It then alerts you to this change and recommends a new
> > >>>> package version number. Alternatively, if you changed the exported
> > >>>> package version, baseline will still tell you that there was a
> > >>>> change made but that you have already correctly changed the package
> > version number.
> > >>>>
> > >>>> HTH,
> > >>>> Justin
> > >>>>
> > >>>> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> > >>>> tom.quarendon@worldprogramming.com> 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.
> > >>>>>
> > >>>>
> > >>>
> > >>> --------------------------------------------------------------------
> > >>> - To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >>> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > >> For additional commands, e-mail: users-help@felix.apache.org
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
>
> --
> http://about.me/milen
>
Re: API baselining with maven-bundle-plugin
Posted by Milen Dyankov <mi...@gmail.com>.
>
> you will be able to build another 1.0.0 locally, but you will not be able
> to release it again
I think that depends on particular Maven repository and it's configuration.
While this is probably true for Central (not sure but would assume so) a
local Nexus repo can be configured to allow re-releasing.
On Fri, Jun 23, 2017 at 7:30 PM, Neil Bartlett <nj...@gmail.com> wrote:
> Hi Tom,
>
> I’m very glad that you’re enjoying the baselining feature of Bndtools so
> much!
>
> I think your expectations are reasonable but we just aren’t quite there
> with bnd/Maven integration.
>
> Bndtools is able to give you immediate baselining errors, but it currently
> only works when bndlib is called directly by Bndtools. In a Maven workspace
> using M2Eclipse, the bundle is built by maven-bundle-plugin or
> bnd-maven-plugin, which of course use bndlib internally, but Bndtools is
> isolated from it by a layer of Maven. The bnd-maven-plugin is run
> incrementally by M2E but we don’t yet have a way to catch the baselining
> errors from bnd-maven-plugin and report them in the IDE. In the future we
> *may* be able to do this, I’m not sure.
>
> So, you won’t get immediate feedback on versioning errors but I would
> still expect the build to be affected as follows:
>
> 1. Package versions will be checked and will fail the build when they are
> incorrect. This is a feature of bnd surfaced through the bnd-maven-plugin.
>
> 2. If you have released version 1.0.0. (i.e. non-SNAPSHOT) of a bundle
> with Maven then you will be able to build another 1.0.0 locally, but you
> will not be able to release it again — this is a built-in feature of Maven.
> At this point you will be forced to bump your bundle version, so it is
> slightly less powerful than bnd baselining which will not even permit you
> to build locally bundle 1.0.0 if it has a delta against the released bundle.
>
> Still, you don’t have to *remember* to bump your versions, the build tool
> will force you to do it eventually.
>
> If a Maven developer would like to check and correct my understanding —
> particularly on point 2 above — please do so!
>
> Thanks,
> Neil
>
>
>
> > On 23 Jun 2017, at 14:26, Tom Quarendon <tom.quarendon@
> worldprogramming.com> wrote:
> >
> > So here's what I've just done in bndtools.
> >
> > Created a project that has three bundles in it, test.api, test.command,
> test.provider. All versions (package, bundle) are initialised to 1.0.0.
> > Set up the project so that it will release to a maven repository.
> > Run the "gradle release" command line option.
> > I now have a "1.0.0" version of the bundle in my maven repository.
> > Set up baselining. This requires nothing more than adding:
> > "-baseline:*"
> > To my build.bnd configuration file. I don't have to say "baseline
> against version X" etc and keep that up to date.
> >
> > Then, literally ALL I did was change the method signature on one of the
> methods.
> > I get, immediately, errors such as:
> > The method 'say(java.lang.String)' was removed, which requires a MAJOR
> change to the package.
> > versioning.test.api: The bundle version (1.0.0/1.0.0) is too low, must
> be at least 2.0.0
> >
> > I resolve all of the issues and I now have my package and bundle version
> numbers at 2.0.0, which is what they need to be given the change in the
> source code.
> > I get the same errors if I run the gradle build that bndtools produces
> for you.
> >
> > Note, I didn't first bump the versions, then make the code change. ALL I
> did was make the code change.
> >
> > So I don't think what I'm trying to do is unreasonable. I don't have to
> remember to bump any versions, I get build failures unless I do. Perfect.
> >
> > This is what I'm trying to replicate, but in a project that wasn't
> originally written with bndtools. I thought maven might be a simpler route
> as it's used elsewhere, and I naively thought I might be able to do it
> using the bnd plugin for maven, since it exposes the baseline facility.
> >
> > Clearly I can't. Clearly my world view doesn't align with maven's.
> That's fine.
> >
> > I will refocus my efforts on trying to do the same thing in gradle,
> where I think I will have more success.
> >
> >
> >
> > -----Original Message-----
> > From: Justin Edelson [mailto:justin@justinedelson.com]
> > Sent: 23 June 2017 14:00
> > To: users@felix.apache.org
> > Subject: Re: API baselining with maven-bundle-plugin
> >
> > On Fri, Jun 23, 2017 at 3:23 AM Tom Quarendon < tom.quarendon@
> worldprogramming.com> wrote:
> >
> >> I get immutable releases. I'm not trying to redefine what 1.0.0 is
> >> with different source code. In fact quite the opposite. I want it to
> >> *prevent me from doing do*. The maven bnd plugin doesn't
> >>
> >> It's the difference between:
> >> "I'm trying to build something that the user wants to call 1.0.0. As
> >> part of that process I'll check whether it conflicts with what is
> >> currently 1.0.0, and if it does I'll fail, not actually creating the
> >> artefact at all, and suggest that they change the version numbers
> appropriately."
> >>
> >
> > If there is already something called "1.0.0", the user shouldn't be
> building something else called "1.0.0". But the detection of that isn't the
> job of the bundle plugin's baseline goal which is solely concerned with
> package versions, not bundle/project versions. What you are talking about
> here is, as I've written previously, typically handled by the release
> process and, as David wrong, enforced at the repository. It would violate
> the SRP for the bundle plugin to get involved with this, especially since
> this problem has absolutely nothing to do with OSGi.
> >
> > Regards,
> > Justin
> >
> >
> >
> >
> >> And
> >> "I'm building something that the user wants to call 1.0.0. Once I've
> >> done that, I'll take that and compare it with another version to see
> >> whether the difference in version numbers, what the user has done to
> >> change the version numbers between those two versions, is consistent
> >> with any changes in the source code, and if not complain. The build
> >> artefact however will now exist".
> >>
> >> I want the former. The maven bnd plugin appears to implement the latter.
> >> As far as I understand, bndtools implements the former, I *can*
> >> implement the former with bnd. It doesn't appear possible to implement
> >> the former with maven due to the way it works.
> >
> >
> >>
> >>
> >> -----Original Message-----
> >> From: Neil Bartlett [mailto:njbartlett@gmail.com]
> >> Sent: 22 June 2017 18:52
> >> To: users@felix.apache.org
> >> Subject: Re: API baselining with maven-bundle-plugin
> >>
> >> Are you sure that you’re actually *releasing* every day? Or do you
> >> only mean sending out snapshots?
> >>
> >> I agree with Justin that releases should be immutable, and that is
> >> what bnd and Bndtools have always tried to achieve. However bnd is not
> >> a complete end-to-end build system like Maven or Gradle, and Bndtools
> >> is only an IDE, so we don’t get a lot of say in the larger process.
> >> You should work within the conventions of whatever build tool you use.
> >>
> >> The process encouraged by bnd is very close to the Maven one. Once a
> >> release is made, you must not change it. If you change a package after
> >> a release, then you move up to a new version number for that package.
> >> You can then build and publish as many snapshot of that new version
> >> number as you like, usually with a timestamp in the qualifier segment
> of the version.
> >> Once you release, that version is consumed and you go back to the
> >> beginning of this paragraph.
> >>
> >> Neil
> >>
> >>
> >>> On 22 Jun 2017, at 18:12, Tom Quarendon <
> >> tom.quarendon@worldprogramming.com> wrote:
> >>>
> >>> The cadence is important I that if I want to "release" off the back
> >>> of
> >> each build, I don't want to have to manually make a code modification
> >> every day, nor do I want to have the build process modify the source
> >> code, that just doesn't seem right.
> >>>
> >>> I'm probably at odds with standard practice.
> >>>
> >>> -----Original Message-----
> >>> From: Justin Edelson [mailto:justin@justinedelson.com]
> >>> Sent: 22 June 2017 17:40
> >>> To: users@felix.apache.org
> >>> Subject: Re: API baselining with maven-bundle-plugin
> >>>
> >>> The cadence of releases is irrelevant. But each release must have a
> >> distinct (bundle) version number. Otherwise, the version loses any
> >> meaning since two copies of "version 1.0.0" are not necessarily the
> same.
> >>>
> >>> If you only want to change the bundle version when you start
> >>> changing the project, that's certainly a choice you can make. I find
> >>> (and many others do
> >>> too) it easier to do this automatically at the time of release (i.e.
> >>> set
> >> the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't
> >> get forgotten.
> >>>
> >>> I can't speak to how bndtools work. I assume it must do some kind of
> >> automatic bundle version management since it would be inappropriate to
> >> have mutable releases.
> >>>
> >>>
> >>> On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
> >> tom.quarendon@worldprogramming.com> wrote:
> >>>
> >>>> I perhaps have a different concept of how things work. But I'm not
> >>>> very familiar with how maven works.
> >>>>
> >>>> Fundamentally, if I haven't changed any code, why have any of the
> >>>> version numbers changed? I'm perhaps viewing things from a
> >>>> continuous deployment perspective rather than a "release once a year"
> perspective.
> >>>>
> >>>> As far as I can tell with bndtools, version numbers are changed as,
> >>>> and only as necessary.
> >>>> I check out the source code, and then as I change code, it prompts
> >>>> me to change package and bundle versions appropriately.
> >>>> Hence after my edits, the package and version numbers of things I
> >>>> haven't changed are the same as they were, which seems right to me.
> >>>> Things that I've changed have changed version package and bundle
> >> version numbers.
> >>>> If I then do a "mvn deploy" (well, "gradle release") on the result,
> >>>> then OK, the unchanged bundles will be re-released to the
> >>>> repository (or maybe not, maybe maven/gradle doesn't replace a
> >>>> bundle with one with the same version, don't know), but the
> >>>> contents are the same (from a source perspective anyhow), so that
> doesn't matter.
> >>>>
> >>>> As I say, I don't have much experience of using maven etc, I was
> >>>> confused that it worked in an apparently different way to bndtools,
> >>>> which is based on the same thing.
> >>>>
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: Justin Edelson [mailto:justin@justinedelson.com]
> >>>> Sent: 22 June 2017 15:15
> >>>> To: users@felix.apache.org
> >>>> Subject: Re: API baselining with maven-bundle-plugin
> >>>>
> >>>> Hi,
> >>>> I think you might be mixing up the bundle version (what I think you
> >>>> are referring to as the "project version") with the package versions.
> >>>> baseline is larger concerned with the latter, and only uses the
> >>>> former to find the comparison version.
> >>>>
> >>>> Released versions should always be considered immutable, so you
> >>>> should
> >>>> *always* change the project version immediately after a release. If
> >>>> you use the maven-release-plugin, this is automatically done, but
> >>>> otherwise you would need to do this manually.
> >>>>
> >>>> Here's the way it is supposed to work:
> >>>>
> >>>> * You have a bundle with version 1.0.0 and package com.myco.foo at
> >>>> version 1.0.0. This bundle is deployed in some repository.
> >>>> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> >>>> 1.0.1-SNAPSHOT in Maven terms).
> >>>> * You make some change to one of the classes/interfaces in
> com.myco.foo.
> >>>> * Then you run the baseline plugin. Baseline compares the current
> >>>> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
> >>>> checks each exported package. It sees that there has been some
> >>>> change in com.myco.foo which requires that the package version
> >>>> change. It then alerts you to this change and recommends a new
> >>>> package version number. Alternatively, if you changed the exported
> >>>> package version, baseline will still tell you that there was a
> >>>> change made but that you have already correctly changed the package
> version number.
> >>>>
> >>>> HTH,
> >>>> Justin
> >>>>
> >>>> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> >>>> tom.quarendon@worldprogramming.com> 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.
> >>>>>
> >>>>
> >>>
> >>> --------------------------------------------------------------------
> >>> - To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >>> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> >> For additional commands, e-mail: users-help@felix.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
--
http://about.me/milen
Re: API baselining with maven-bundle-plugin
Posted by Neil Bartlett <nj...@gmail.com>.
Hi Tom,
I’m very glad that you’re enjoying the baselining feature of Bndtools so much!
I think your expectations are reasonable but we just aren’t quite there with bnd/Maven integration.
Bndtools is able to give you immediate baselining errors, but it currently only works when bndlib is called directly by Bndtools. In a Maven workspace using M2Eclipse, the bundle is built by maven-bundle-plugin or bnd-maven-plugin, which of course use bndlib internally, but Bndtools is isolated from it by a layer of Maven. The bnd-maven-plugin is run incrementally by M2E but we don’t yet have a way to catch the baselining errors from bnd-maven-plugin and report them in the IDE. In the future we *may* be able to do this, I’m not sure.
So, you won’t get immediate feedback on versioning errors but I would still expect the build to be affected as follows:
1. Package versions will be checked and will fail the build when they are incorrect. This is a feature of bnd surfaced through the bnd-maven-plugin.
2. If you have released version 1.0.0. (i.e. non-SNAPSHOT) of a bundle with Maven then you will be able to build another 1.0.0 locally, but you will not be able to release it again — this is a built-in feature of Maven. At this point you will be forced to bump your bundle version, so it is slightly less powerful than bnd baselining which will not even permit you to build locally bundle 1.0.0 if it has a delta against the released bundle.
Still, you don’t have to *remember* to bump your versions, the build tool will force you to do it eventually.
If a Maven developer would like to check and correct my understanding — particularly on point 2 above — please do so!
Thanks,
Neil
> On 23 Jun 2017, at 14:26, Tom Quarendon <to...@worldprogramming.com> wrote:
>
> So here's what I've just done in bndtools.
>
> Created a project that has three bundles in it, test.api, test.command, test.provider. All versions (package, bundle) are initialised to 1.0.0.
> Set up the project so that it will release to a maven repository.
> Run the "gradle release" command line option.
> I now have a "1.0.0" version of the bundle in my maven repository.
> Set up baselining. This requires nothing more than adding:
> "-baseline:*"
> To my build.bnd configuration file. I don't have to say "baseline against version X" etc and keep that up to date.
>
> Then, literally ALL I did was change the method signature on one of the methods.
> I get, immediately, errors such as:
> The method 'say(java.lang.String)' was removed, which requires a MAJOR change to the package.
> versioning.test.api: The bundle version (1.0.0/1.0.0) is too low, must be at least 2.0.0
>
> I resolve all of the issues and I now have my package and bundle version numbers at 2.0.0, which is what they need to be given the change in the source code.
> I get the same errors if I run the gradle build that bndtools produces for you.
>
> Note, I didn't first bump the versions, then make the code change. ALL I did was make the code change.
>
> So I don't think what I'm trying to do is unreasonable. I don't have to remember to bump any versions, I get build failures unless I do. Perfect.
>
> This is what I'm trying to replicate, but in a project that wasn't originally written with bndtools. I thought maven might be a simpler route as it's used elsewhere, and I naively thought I might be able to do it using the bnd plugin for maven, since it exposes the baseline facility.
>
> Clearly I can't. Clearly my world view doesn't align with maven's. That's fine.
>
> I will refocus my efforts on trying to do the same thing in gradle, where I think I will have more success.
>
>
>
> -----Original Message-----
> From: Justin Edelson [mailto:justin@justinedelson.com]
> Sent: 23 June 2017 14:00
> To: users@felix.apache.org
> Subject: Re: API baselining with maven-bundle-plugin
>
> On Fri, Jun 23, 2017 at 3:23 AM Tom Quarendon < tom.quarendon@worldprogramming.com> wrote:
>
>> I get immutable releases. I'm not trying to redefine what 1.0.0 is
>> with different source code. In fact quite the opposite. I want it to
>> *prevent me from doing do*. The maven bnd plugin doesn't
>>
>> It's the difference between:
>> "I'm trying to build something that the user wants to call 1.0.0. As
>> part of that process I'll check whether it conflicts with what is
>> currently 1.0.0, and if it does I'll fail, not actually creating the
>> artefact at all, and suggest that they change the version numbers appropriately."
>>
>
> If there is already something called "1.0.0", the user shouldn't be building something else called "1.0.0". But the detection of that isn't the job of the bundle plugin's baseline goal which is solely concerned with package versions, not bundle/project versions. What you are talking about here is, as I've written previously, typically handled by the release process and, as David wrong, enforced at the repository. It would violate the SRP for the bundle plugin to get involved with this, especially since this problem has absolutely nothing to do with OSGi.
>
> Regards,
> Justin
>
>
>
>
>> And
>> "I'm building something that the user wants to call 1.0.0. Once I've
>> done that, I'll take that and compare it with another version to see
>> whether the difference in version numbers, what the user has done to
>> change the version numbers between those two versions, is consistent
>> with any changes in the source code, and if not complain. The build
>> artefact however will now exist".
>>
>> I want the former. The maven bnd plugin appears to implement the latter.
>> As far as I understand, bndtools implements the former, I *can*
>> implement the former with bnd. It doesn't appear possible to implement
>> the former with maven due to the way it works.
>
>
>>
>>
>> -----Original Message-----
>> From: Neil Bartlett [mailto:njbartlett@gmail.com]
>> Sent: 22 June 2017 18:52
>> To: users@felix.apache.org
>> Subject: Re: API baselining with maven-bundle-plugin
>>
>> Are you sure that you’re actually *releasing* every day? Or do you
>> only mean sending out snapshots?
>>
>> I agree with Justin that releases should be immutable, and that is
>> what bnd and Bndtools have always tried to achieve. However bnd is not
>> a complete end-to-end build system like Maven or Gradle, and Bndtools
>> is only an IDE, so we don’t get a lot of say in the larger process.
>> You should work within the conventions of whatever build tool you use.
>>
>> The process encouraged by bnd is very close to the Maven one. Once a
>> release is made, you must not change it. If you change a package after
>> a release, then you move up to a new version number for that package.
>> You can then build and publish as many snapshot of that new version
>> number as you like, usually with a timestamp in the qualifier segment of the version.
>> Once you release, that version is consumed and you go back to the
>> beginning of this paragraph.
>>
>> Neil
>>
>>
>>> On 22 Jun 2017, at 18:12, Tom Quarendon <
>> tom.quarendon@worldprogramming.com> wrote:
>>>
>>> The cadence is important I that if I want to "release" off the back
>>> of
>> each build, I don't want to have to manually make a code modification
>> every day, nor do I want to have the build process modify the source
>> code, that just doesn't seem right.
>>>
>>> I'm probably at odds with standard practice.
>>>
>>> -----Original Message-----
>>> From: Justin Edelson [mailto:justin@justinedelson.com]
>>> Sent: 22 June 2017 17:40
>>> To: users@felix.apache.org
>>> Subject: Re: API baselining with maven-bundle-plugin
>>>
>>> The cadence of releases is irrelevant. But each release must have a
>> distinct (bundle) version number. Otherwise, the version loses any
>> meaning since two copies of "version 1.0.0" are not necessarily the same.
>>>
>>> If you only want to change the bundle version when you start
>>> changing the project, that's certainly a choice you can make. I find
>>> (and many others do
>>> too) it easier to do this automatically at the time of release (i.e.
>>> set
>> the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't
>> get forgotten.
>>>
>>> I can't speak to how bndtools work. I assume it must do some kind of
>> automatic bundle version management since it would be inappropriate to
>> have mutable releases.
>>>
>>>
>>> On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
>> tom.quarendon@worldprogramming.com> wrote:
>>>
>>>> I perhaps have a different concept of how things work. But I'm not
>>>> very familiar with how maven works.
>>>>
>>>> Fundamentally, if I haven't changed any code, why have any of the
>>>> version numbers changed? I'm perhaps viewing things from a
>>>> continuous deployment perspective rather than a "release once a year" perspective.
>>>>
>>>> As far as I can tell with bndtools, version numbers are changed as,
>>>> and only as necessary.
>>>> I check out the source code, and then as I change code, it prompts
>>>> me to change package and bundle versions appropriately.
>>>> Hence after my edits, the package and version numbers of things I
>>>> haven't changed are the same as they were, which seems right to me.
>>>> Things that I've changed have changed version package and bundle
>> version numbers.
>>>> If I then do a "mvn deploy" (well, "gradle release") on the result,
>>>> then OK, the unchanged bundles will be re-released to the
>>>> repository (or maybe not, maybe maven/gradle doesn't replace a
>>>> bundle with one with the same version, don't know), but the
>>>> contents are the same (from a source perspective anyhow), so that doesn't matter.
>>>>
>>>> As I say, I don't have much experience of using maven etc, I was
>>>> confused that it worked in an apparently different way to bndtools,
>>>> which is based on the same thing.
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: Justin Edelson [mailto:justin@justinedelson.com]
>>>> Sent: 22 June 2017 15:15
>>>> To: users@felix.apache.org
>>>> Subject: Re: API baselining with maven-bundle-plugin
>>>>
>>>> Hi,
>>>> I think you might be mixing up the bundle version (what I think you
>>>> are referring to as the "project version") with the package versions.
>>>> baseline is larger concerned with the latter, and only uses the
>>>> former to find the comparison version.
>>>>
>>>> Released versions should always be considered immutable, so you
>>>> should
>>>> *always* change the project version immediately after a release. If
>>>> you use the maven-release-plugin, this is automatically done, but
>>>> otherwise you would need to do this manually.
>>>>
>>>> Here's the way it is supposed to work:
>>>>
>>>> * You have a bundle with version 1.0.0 and package com.myco.foo at
>>>> version 1.0.0. This bundle is deployed in some repository.
>>>> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
>>>> 1.0.1-SNAPSHOT in Maven terms).
>>>> * You make some change to one of the classes/interfaces in com.myco.foo.
>>>> * Then you run the baseline plugin. Baseline compares the current
>>>> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
>>>> checks each exported package. It sees that there has been some
>>>> change in com.myco.foo which requires that the package version
>>>> change. It then alerts you to this change and recommends a new
>>>> package version number. Alternatively, if you changed the exported
>>>> package version, baseline will still tell you that there was a
>>>> change made but that you have already correctly changed the package version number.
>>>>
>>>> HTH,
>>>> Justin
>>>>
>>>> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
>>>> tom.quarendon@worldprogramming.com> 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.
>>>>>
>>>>
>>>
>>> --------------------------------------------------------------------
>>> - To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: API baselining with maven-bundle-plugin
Posted by Tom Quarendon <to...@worldprogramming.com>.
So here's what I've just done in bndtools.
Created a project that has three bundles in it, test.api, test.command, test.provider. All versions (package, bundle) are initialised to 1.0.0.
Set up the project so that it will release to a maven repository.
Run the "gradle release" command line option.
I now have a "1.0.0" version of the bundle in my maven repository.
Set up baselining. This requires nothing more than adding:
"-baseline:*"
To my build.bnd configuration file. I don't have to say "baseline against version X" etc and keep that up to date.
Then, literally ALL I did was change the method signature on one of the methods.
I get, immediately, errors such as:
The method 'say(java.lang.String)' was removed, which requires a MAJOR change to the package.
versioning.test.api: The bundle version (1.0.0/1.0.0) is too low, must be at least 2.0.0
I resolve all of the issues and I now have my package and bundle version numbers at 2.0.0, which is what they need to be given the change in the source code.
I get the same errors if I run the gradle build that bndtools produces for you.
Note, I didn't first bump the versions, then make the code change. ALL I did was make the code change.
So I don't think what I'm trying to do is unreasonable. I don't have to remember to bump any versions, I get build failures unless I do. Perfect.
This is what I'm trying to replicate, but in a project that wasn't originally written with bndtools. I thought maven might be a simpler route as it's used elsewhere, and I naively thought I might be able to do it using the bnd plugin for maven, since it exposes the baseline facility.
Clearly I can't. Clearly my world view doesn't align with maven's. That's fine.
I will refocus my efforts on trying to do the same thing in gradle, where I think I will have more success.
-----Original Message-----
From: Justin Edelson [mailto:justin@justinedelson.com]
Sent: 23 June 2017 14:00
To: users@felix.apache.org
Subject: Re: API baselining with maven-bundle-plugin
On Fri, Jun 23, 2017 at 3:23 AM Tom Quarendon < tom.quarendon@worldprogramming.com> wrote:
> I get immutable releases. I'm not trying to redefine what 1.0.0 is
> with different source code. In fact quite the opposite. I want it to
> *prevent me from doing do*. The maven bnd plugin doesn't
>
> It's the difference between:
> "I'm trying to build something that the user wants to call 1.0.0. As
> part of that process I'll check whether it conflicts with what is
> currently 1.0.0, and if it does I'll fail, not actually creating the
> artefact at all, and suggest that they change the version numbers appropriately."
>
If there is already something called "1.0.0", the user shouldn't be building something else called "1.0.0". But the detection of that isn't the job of the bundle plugin's baseline goal which is solely concerned with package versions, not bundle/project versions. What you are talking about here is, as I've written previously, typically handled by the release process and, as David wrong, enforced at the repository. It would violate the SRP for the bundle plugin to get involved with this, especially since this problem has absolutely nothing to do with OSGi.
Regards,
Justin
> And
> "I'm building something that the user wants to call 1.0.0. Once I've
> done that, I'll take that and compare it with another version to see
> whether the difference in version numbers, what the user has done to
> change the version numbers between those two versions, is consistent
> with any changes in the source code, and if not complain. The build
> artefact however will now exist".
>
> I want the former. The maven bnd plugin appears to implement the latter.
> As far as I understand, bndtools implements the former, I *can*
> implement the former with bnd. It doesn't appear possible to implement
> the former with maven due to the way it works.
>
>
> -----Original Message-----
> From: Neil Bartlett [mailto:njbartlett@gmail.com]
> Sent: 22 June 2017 18:52
> To: users@felix.apache.org
> Subject: Re: API baselining with maven-bundle-plugin
>
> Are you sure that you’re actually *releasing* every day? Or do you
> only mean sending out snapshots?
>
> I agree with Justin that releases should be immutable, and that is
> what bnd and Bndtools have always tried to achieve. However bnd is not
> a complete end-to-end build system like Maven or Gradle, and Bndtools
> is only an IDE, so we don’t get a lot of say in the larger process.
> You should work within the conventions of whatever build tool you use.
>
> The process encouraged by bnd is very close to the Maven one. Once a
> release is made, you must not change it. If you change a package after
> a release, then you move up to a new version number for that package.
> You can then build and publish as many snapshot of that new version
> number as you like, usually with a timestamp in the qualifier segment of the version.
> Once you release, that version is consumed and you go back to the
> beginning of this paragraph.
>
> Neil
>
>
> > On 22 Jun 2017, at 18:12, Tom Quarendon <
> tom.quarendon@worldprogramming.com> wrote:
> >
> > The cadence is important I that if I want to "release" off the back
> > of
> each build, I don't want to have to manually make a code modification
> every day, nor do I want to have the build process modify the source
> code, that just doesn't seem right.
> >
> > I'm probably at odds with standard practice.
> >
> > -----Original Message-----
> > From: Justin Edelson [mailto:justin@justinedelson.com]
> > Sent: 22 June 2017 17:40
> > To: users@felix.apache.org
> > Subject: Re: API baselining with maven-bundle-plugin
> >
> > The cadence of releases is irrelevant. But each release must have a
> distinct (bundle) version number. Otherwise, the version loses any
> meaning since two copies of "version 1.0.0" are not necessarily the same.
> >
> > If you only want to change the bundle version when you start
> > changing the project, that's certainly a choice you can make. I find
> > (and many others do
> > too) it easier to do this automatically at the time of release (i.e.
> > set
> the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't
> get forgotten.
> >
> > I can't speak to how bndtools work. I assume it must do some kind of
> automatic bundle version management since it would be inappropriate to
> have mutable releases.
> >
> >
> > On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
> tom.quarendon@worldprogramming.com> wrote:
> >
> >> I perhaps have a different concept of how things work. But I'm not
> >> very familiar with how maven works.
> >>
> >> Fundamentally, if I haven't changed any code, why have any of the
> >> version numbers changed? I'm perhaps viewing things from a
> >> continuous deployment perspective rather than a "release once a year" perspective.
> >>
> >> As far as I can tell with bndtools, version numbers are changed as,
> >> and only as necessary.
> >> I check out the source code, and then as I change code, it prompts
> >> me to change package and bundle versions appropriately.
> >> Hence after my edits, the package and version numbers of things I
> >> haven't changed are the same as they were, which seems right to me.
> >> Things that I've changed have changed version package and bundle
> version numbers.
> >> If I then do a "mvn deploy" (well, "gradle release") on the result,
> >> then OK, the unchanged bundles will be re-released to the
> >> repository (or maybe not, maybe maven/gradle doesn't replace a
> >> bundle with one with the same version, don't know), but the
> >> contents are the same (from a source perspective anyhow), so that doesn't matter.
> >>
> >> As I say, I don't have much experience of using maven etc, I was
> >> confused that it worked in an apparently different way to bndtools,
> >> which is based on the same thing.
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Justin Edelson [mailto:justin@justinedelson.com]
> >> Sent: 22 June 2017 15:15
> >> To: users@felix.apache.org
> >> Subject: Re: API baselining with maven-bundle-plugin
> >>
> >> Hi,
> >> I think you might be mixing up the bundle version (what I think you
> >> are referring to as the "project version") with the package versions.
> >> baseline is larger concerned with the latter, and only uses the
> >> former to find the comparison version.
> >>
> >> Released versions should always be considered immutable, so you
> >> should
> >> *always* change the project version immediately after a release. If
> >> you use the maven-release-plugin, this is automatically done, but
> >> otherwise you would need to do this manually.
> >>
> >> Here's the way it is supposed to work:
> >>
> >> * You have a bundle with version 1.0.0 and package com.myco.foo at
> >> version 1.0.0. This bundle is deployed in some repository.
> >> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> >> 1.0.1-SNAPSHOT in Maven terms).
> >> * You make some change to one of the classes/interfaces in com.myco.foo.
> >> * Then you run the baseline plugin. Baseline compares the current
> >> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
> >> checks each exported package. It sees that there has been some
> >> change in com.myco.foo which requires that the package version
> >> change. It then alerts you to this change and recommends a new
> >> package version number. Alternatively, if you changed the exported
> >> package version, baseline will still tell you that there was a
> >> change made but that you have already correctly changed the package version number.
> >>
> >> HTH,
> >> Justin
> >>
> >> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> >> tom.quarendon@worldprogramming.com> 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.
> >>>
> >>
> >
> > --------------------------------------------------------------------
> > - To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: API baselining with maven-bundle-plugin
Posted by Justin Edelson <ju...@justinedelson.com>.
On Fri, Jun 23, 2017 at 3:23 AM Tom Quarendon <
tom.quarendon@worldprogramming.com> wrote:
> I get immutable releases. I'm not trying to redefine what 1.0.0 is with
> different source code. In fact quite the opposite. I want it to *prevent me
> from doing do*. The maven bnd plugin doesn't
>
> It's the difference between:
> "I'm trying to build something that the user wants to call 1.0.0. As
> part of that process I'll check whether it conflicts with what is currently
> 1.0.0, and if it does I'll fail, not actually creating the artefact at all,
> and suggest that they change the version numbers appropriately."
>
If there is already something called "1.0.0", the user shouldn't be
building something else called "1.0.0". But the detection of that isn't the
job of the bundle plugin's baseline goal which is solely concerned with
package versions, not bundle/project versions. What you are talking about
here is, as I've written previously, typically handled by the release
process and, as David wrong, enforced at the repository. It would violate
the SRP for the bundle plugin to get involved with this, especially since
this problem has absolutely nothing to do with OSGi.
Regards,
Justin
> And
> "I'm building something that the user wants to call 1.0.0. Once I've
> done that, I'll take that and compare it with another version to see
> whether the difference in version numbers, what the user has done to change
> the version numbers between those two versions, is consistent with any
> changes in the source code, and if not complain. The build artefact however
> will now exist".
>
> I want the former. The maven bnd plugin appears to implement the latter.
> As far as I understand, bndtools implements the former, I *can* implement
> the former with bnd. It doesn't appear possible to implement the former
> with maven due to the way it works.
>
>
> -----Original Message-----
> From: Neil Bartlett [mailto:njbartlett@gmail.com]
> Sent: 22 June 2017 18:52
> To: users@felix.apache.org
> Subject: Re: API baselining with maven-bundle-plugin
>
> Are you sure that you’re actually *releasing* every day? Or do you only
> mean sending out snapshots?
>
> I agree with Justin that releases should be immutable, and that is what
> bnd and Bndtools have always tried to achieve. However bnd is not a
> complete end-to-end build system like Maven or Gradle, and Bndtools is only
> an IDE, so we don’t get a lot of say in the larger process. You should work
> within the conventions of whatever build tool you use.
>
> The process encouraged by bnd is very close to the Maven one. Once a
> release is made, you must not change it. If you change a package after a
> release, then you move up to a new version number for that package. You can
> then build and publish as many snapshot of that new version number as you
> like, usually with a timestamp in the qualifier segment of the version.
> Once you release, that version is consumed and you go back to the beginning
> of this paragraph.
>
> Neil
>
>
> > On 22 Jun 2017, at 18:12, Tom Quarendon <
> tom.quarendon@worldprogramming.com> wrote:
> >
> > The cadence is important I that if I want to "release" off the back of
> each build, I don't want to have to manually make a code modification every
> day, nor do I want to have the build process modify the source code, that
> just doesn't seem right.
> >
> > I'm probably at odds with standard practice.
> >
> > -----Original Message-----
> > From: Justin Edelson [mailto:justin@justinedelson.com]
> > Sent: 22 June 2017 17:40
> > To: users@felix.apache.org
> > Subject: Re: API baselining with maven-bundle-plugin
> >
> > The cadence of releases is irrelevant. But each release must have a
> distinct (bundle) version number. Otherwise, the version loses any meaning
> since two copies of "version 1.0.0" are not necessarily the same.
> >
> > If you only want to change the bundle version when you start changing
> > the project, that's certainly a choice you can make. I find (and many
> > others do
> > too) it easier to do this automatically at the time of release (i.e. set
> the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't get
> forgotten.
> >
> > I can't speak to how bndtools work. I assume it must do some kind of
> automatic bundle version management since it would be inappropriate to have
> mutable releases.
> >
> >
> > On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
> tom.quarendon@worldprogramming.com> wrote:
> >
> >> I perhaps have a different concept of how things work. But I'm not
> >> very familiar with how maven works.
> >>
> >> Fundamentally, if I haven't changed any code, why have any of the
> >> version numbers changed? I'm perhaps viewing things from a continuous
> >> deployment perspective rather than a "release once a year" perspective.
> >>
> >> As far as I can tell with bndtools, version numbers are changed as,
> >> and only as necessary.
> >> I check out the source code, and then as I change code, it prompts me
> >> to change package and bundle versions appropriately.
> >> Hence after my edits, the package and version numbers of things I
> >> haven't changed are the same as they were, which seems right to me.
> >> Things that I've changed have changed version package and bundle
> version numbers.
> >> If I then do a "mvn deploy" (well, "gradle release") on the result,
> >> then OK, the unchanged bundles will be re-released to the repository
> >> (or maybe not, maybe maven/gradle doesn't replace a bundle with one
> >> with the same version, don't know), but the contents are the same
> >> (from a source perspective anyhow), so that doesn't matter.
> >>
> >> As I say, I don't have much experience of using maven etc, I was
> >> confused that it worked in an apparently different way to bndtools,
> >> which is based on the same thing.
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Justin Edelson [mailto:justin@justinedelson.com]
> >> Sent: 22 June 2017 15:15
> >> To: users@felix.apache.org
> >> Subject: Re: API baselining with maven-bundle-plugin
> >>
> >> Hi,
> >> I think you might be mixing up the bundle version (what I think you
> >> are referring to as the "project version") with the package versions.
> >> baseline is larger concerned with the latter, and only uses the
> >> former to find the comparison version.
> >>
> >> Released versions should always be considered immutable, so you
> >> should
> >> *always* change the project version immediately after a release. If
> >> you use the maven-release-plugin, this is automatically done, but
> >> otherwise you would need to do this manually.
> >>
> >> Here's the way it is supposed to work:
> >>
> >> * You have a bundle with version 1.0.0 and package com.myco.foo at
> >> version 1.0.0. This bundle is deployed in some repository.
> >> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> >> 1.0.1-SNAPSHOT in Maven terms).
> >> * You make some change to one of the classes/interfaces in com.myco.foo.
> >> * Then you run the baseline plugin. Baseline compares the current
> >> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
> >> checks each exported package. It sees that there has been some change
> >> in com.myco.foo which requires that the package version change. It
> >> then alerts you to this change and recommends a new package version
> >> number. Alternatively, if you changed the exported package version,
> >> baseline will still tell you that there was a change made but that
> >> you have already correctly changed the package version number.
> >>
> >> HTH,
> >> Justin
> >>
> >> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> >> tom.quarendon@worldprogramming.com> 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.
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: API baselining with maven-bundle-plugin
Posted by David Leangen <os...@leangen.net>.
I was having a similar problem, but I resolved it a bit differently.
I don’t use Maven, but the way I resolved this was to enforce this behaviour on my Nexus repository. So, when I release from the CI server to the remote repo, bnd does not care. If the artefact already exists, it just doesn’t get uploaded.
YMMV
Cheers,
=David
> On Jun 23, 2017, at 4:23 PM, Tom Quarendon <to...@worldprogramming.com> wrote:
>
> I get immutable releases. I'm not trying to redefine what 1.0.0 is with different source code. In fact quite the opposite. I want it to *prevent me from doing do*. The maven bnd plugin doesn't
>
> It's the difference between:
> "I'm trying to build something that the user wants to call 1.0.0. As part of that process I'll check whether it conflicts with what is currently 1.0.0, and if it does I'll fail, not actually creating the artefact at all, and suggest that they change the version numbers appropriately."
> And
> "I'm building something that the user wants to call 1.0.0. Once I've done that, I'll take that and compare it with another version to see whether the difference in version numbers, what the user has done to change the version numbers between those two versions, is consistent with any changes in the source code, and if not complain. The build artefact however will now exist".
>
> I want the former. The maven bnd plugin appears to implement the latter. As far as I understand, bndtools implements the former, I *can* implement the former with bnd. It doesn't appear possible to implement the former with maven due to the way it works.
>
>
>
> -----Original Message-----
> From: Neil Bartlett [mailto:njbartlett@gmail.com]
> Sent: 22 June 2017 18:52
> To: users@felix.apache.org
> Subject: Re: API baselining with maven-bundle-plugin
>
> Are you sure that you’re actually *releasing* every day? Or do you only mean sending out snapshots?
>
> I agree with Justin that releases should be immutable, and that is what bnd and Bndtools have always tried to achieve. However bnd is not a complete end-to-end build system like Maven or Gradle, and Bndtools is only an IDE, so we don’t get a lot of say in the larger process. You should work within the conventions of whatever build tool you use.
>
> The process encouraged by bnd is very close to the Maven one. Once a release is made, you must not change it. If you change a package after a release, then you move up to a new version number for that package. You can then build and publish as many snapshot of that new version number as you like, usually with a timestamp in the qualifier segment of the version. Once you release, that version is consumed and you go back to the beginning of this paragraph.
>
> Neil
>
>
>> On 22 Jun 2017, at 18:12, Tom Quarendon <to...@worldprogramming.com> wrote:
>>
>> The cadence is important I that if I want to "release" off the back of each build, I don't want to have to manually make a code modification every day, nor do I want to have the build process modify the source code, that just doesn't seem right.
>>
>> I'm probably at odds with standard practice.
>>
>> -----Original Message-----
>> From: Justin Edelson [mailto:justin@justinedelson.com]
>> Sent: 22 June 2017 17:40
>> To: users@felix.apache.org
>> Subject: Re: API baselining with maven-bundle-plugin
>>
>> The cadence of releases is irrelevant. But each release must have a distinct (bundle) version number. Otherwise, the version loses any meaning since two copies of "version 1.0.0" are not necessarily the same.
>>
>> If you only want to change the bundle version when you start changing
>> the project, that's certainly a choice you can make. I find (and many
>> others do
>> too) it easier to do this automatically at the time of release (i.e. set the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't get forgotten.
>>
>> I can't speak to how bndtools work. I assume it must do some kind of automatic bundle version management since it would be inappropriate to have mutable releases.
>>
>>
>> On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon < tom.quarendon@worldprogramming.com> wrote:
>>
>>> I perhaps have a different concept of how things work. But I'm not
>>> very familiar with how maven works.
>>>
>>> Fundamentally, if I haven't changed any code, why have any of the
>>> version numbers changed? I'm perhaps viewing things from a continuous
>>> deployment perspective rather than a "release once a year" perspective.
>>>
>>> As far as I can tell with bndtools, version numbers are changed as,
>>> and only as necessary.
>>> I check out the source code, and then as I change code, it prompts me
>>> to change package and bundle versions appropriately.
>>> Hence after my edits, the package and version numbers of things I
>>> haven't changed are the same as they were, which seems right to me.
>>> Things that I've changed have changed version package and bundle version numbers.
>>> If I then do a "mvn deploy" (well, "gradle release") on the result,
>>> then OK, the unchanged bundles will be re-released to the repository
>>> (or maybe not, maybe maven/gradle doesn't replace a bundle with one
>>> with the same version, don't know), but the contents are the same
>>> (from a source perspective anyhow), so that doesn't matter.
>>>
>>> As I say, I don't have much experience of using maven etc, I was
>>> confused that it worked in an apparently different way to bndtools,
>>> which is based on the same thing.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Justin Edelson [mailto:justin@justinedelson.com]
>>> Sent: 22 June 2017 15:15
>>> To: users@felix.apache.org
>>> Subject: Re: API baselining with maven-bundle-plugin
>>>
>>> Hi,
>>> I think you might be mixing up the bundle version (what I think you
>>> are referring to as the "project version") with the package versions.
>>> baseline is larger concerned with the latter, and only uses the
>>> former to find the comparison version.
>>>
>>> Released versions should always be considered immutable, so you
>>> should
>>> *always* change the project version immediately after a release. If
>>> you use the maven-release-plugin, this is automatically done, but
>>> otherwise you would need to do this manually.
>>>
>>> Here's the way it is supposed to work:
>>>
>>> * You have a bundle with version 1.0.0 and package com.myco.foo at
>>> version 1.0.0. This bundle is deployed in some repository.
>>> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
>>> 1.0.1-SNAPSHOT in Maven terms).
>>> * You make some change to one of the classes/interfaces in com.myco.foo.
>>> * Then you run the baseline plugin. Baseline compares the current
>>> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
>>> checks each exported package. It sees that there has been some change
>>> in com.myco.foo which requires that the package version change. It
>>> then alerts you to this change and recommends a new package version
>>> number. Alternatively, if you changed the exported package version,
>>> baseline will still tell you that there was a change made but that
>>> you have already correctly changed the package version number.
>>>
>>> HTH,
>>> Justin
>>>
>>> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
>>> tom.quarendon@worldprogramming.com> 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.
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: API baselining with maven-bundle-plugin
Posted by Tom Quarendon <to...@worldprogramming.com>.
I get immutable releases. I'm not trying to redefine what 1.0.0 is with different source code. In fact quite the opposite. I want it to *prevent me from doing do*. The maven bnd plugin doesn't
It's the difference between:
"I'm trying to build something that the user wants to call 1.0.0. As part of that process I'll check whether it conflicts with what is currently 1.0.0, and if it does I'll fail, not actually creating the artefact at all, and suggest that they change the version numbers appropriately."
And
"I'm building something that the user wants to call 1.0.0. Once I've done that, I'll take that and compare it with another version to see whether the difference in version numbers, what the user has done to change the version numbers between those two versions, is consistent with any changes in the source code, and if not complain. The build artefact however will now exist".
I want the former. The maven bnd plugin appears to implement the latter. As far as I understand, bndtools implements the former, I *can* implement the former with bnd. It doesn't appear possible to implement the former with maven due to the way it works.
-----Original Message-----
From: Neil Bartlett [mailto:njbartlett@gmail.com]
Sent: 22 June 2017 18:52
To: users@felix.apache.org
Subject: Re: API baselining with maven-bundle-plugin
Are you sure that you’re actually *releasing* every day? Or do you only mean sending out snapshots?
I agree with Justin that releases should be immutable, and that is what bnd and Bndtools have always tried to achieve. However bnd is not a complete end-to-end build system like Maven or Gradle, and Bndtools is only an IDE, so we don’t get a lot of say in the larger process. You should work within the conventions of whatever build tool you use.
The process encouraged by bnd is very close to the Maven one. Once a release is made, you must not change it. If you change a package after a release, then you move up to a new version number for that package. You can then build and publish as many snapshot of that new version number as you like, usually with a timestamp in the qualifier segment of the version. Once you release, that version is consumed and you go back to the beginning of this paragraph.
Neil
> On 22 Jun 2017, at 18:12, Tom Quarendon <to...@worldprogramming.com> wrote:
>
> The cadence is important I that if I want to "release" off the back of each build, I don't want to have to manually make a code modification every day, nor do I want to have the build process modify the source code, that just doesn't seem right.
>
> I'm probably at odds with standard practice.
>
> -----Original Message-----
> From: Justin Edelson [mailto:justin@justinedelson.com]
> Sent: 22 June 2017 17:40
> To: users@felix.apache.org
> Subject: Re: API baselining with maven-bundle-plugin
>
> The cadence of releases is irrelevant. But each release must have a distinct (bundle) version number. Otherwise, the version loses any meaning since two copies of "version 1.0.0" are not necessarily the same.
>
> If you only want to change the bundle version when you start changing
> the project, that's certainly a choice you can make. I find (and many
> others do
> too) it easier to do this automatically at the time of release (i.e. set the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't get forgotten.
>
> I can't speak to how bndtools work. I assume it must do some kind of automatic bundle version management since it would be inappropriate to have mutable releases.
>
>
> On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon < tom.quarendon@worldprogramming.com> wrote:
>
>> I perhaps have a different concept of how things work. But I'm not
>> very familiar with how maven works.
>>
>> Fundamentally, if I haven't changed any code, why have any of the
>> version numbers changed? I'm perhaps viewing things from a continuous
>> deployment perspective rather than a "release once a year" perspective.
>>
>> As far as I can tell with bndtools, version numbers are changed as,
>> and only as necessary.
>> I check out the source code, and then as I change code, it prompts me
>> to change package and bundle versions appropriately.
>> Hence after my edits, the package and version numbers of things I
>> haven't changed are the same as they were, which seems right to me.
>> Things that I've changed have changed version package and bundle version numbers.
>> If I then do a "mvn deploy" (well, "gradle release") on the result,
>> then OK, the unchanged bundles will be re-released to the repository
>> (or maybe not, maybe maven/gradle doesn't replace a bundle with one
>> with the same version, don't know), but the contents are the same
>> (from a source perspective anyhow), so that doesn't matter.
>>
>> As I say, I don't have much experience of using maven etc, I was
>> confused that it worked in an apparently different way to bndtools,
>> which is based on the same thing.
>>
>>
>>
>> -----Original Message-----
>> From: Justin Edelson [mailto:justin@justinedelson.com]
>> Sent: 22 June 2017 15:15
>> To: users@felix.apache.org
>> Subject: Re: API baselining with maven-bundle-plugin
>>
>> Hi,
>> I think you might be mixing up the bundle version (what I think you
>> are referring to as the "project version") with the package versions.
>> baseline is larger concerned with the latter, and only uses the
>> former to find the comparison version.
>>
>> Released versions should always be considered immutable, so you
>> should
>> *always* change the project version immediately after a release. If
>> you use the maven-release-plugin, this is automatically done, but
>> otherwise you would need to do this manually.
>>
>> Here's the way it is supposed to work:
>>
>> * You have a bundle with version 1.0.0 and package com.myco.foo at
>> version 1.0.0. This bundle is deployed in some repository.
>> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
>> 1.0.1-SNAPSHOT in Maven terms).
>> * You make some change to one of the classes/interfaces in com.myco.foo.
>> * Then you run the baseline plugin. Baseline compares the current
>> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
>> checks each exported package. It sees that there has been some change
>> in com.myco.foo which requires that the package version change. It
>> then alerts you to this change and recommends a new package version
>> number. Alternatively, if you changed the exported package version,
>> baseline will still tell you that there was a change made but that
>> you have already correctly changed the package version number.
>>
>> HTH,
>> Justin
>>
>> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
>> tom.quarendon@worldprogramming.com> 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.
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: API baselining with maven-bundle-plugin
Posted by David Leangen <os...@leangen.net>.
Hi Justin,
> On Jun 23, 2017, at 4:11 AM, Justin Edelson <ju...@justinedelson.com> wrote:
>
> So in that case, does the timestamp qualifier get automatically added on
> every build? Documentation pointers welcome :)
Warning: I am not so familiar with Maven...
The version number depends on how it is defined in the bnd file. It is up to you to define it.
If you do *not* want the timestamp, you could set the version to, for example: 1.0.0.
If you *do* want the timestamp, you could set the version to 1.0.0.${tstamp}.
You could also use a versionmask [1] like this:
****
base.version: 1.0.0
Bundle-Version: ${versionmask;===~;${base.version}}
****
You could even use or not use the timestamp by including a conditional like this:
Bundle-Version: ${versionmask;${if;[CONDITION];====;===~};${base.version}}
There are many ways to skin this cat. Hope this helps.
[1] http://bnd.bndtools.org/macros/versionmask.html <http://bnd.bndtools.org/macros/versionmask.html>
Cheers,
=David
Re: API baselining with maven-bundle-plugin
Posted by Justin Edelson <ju...@justinedelson.com>.
So in that case, does the timestamp qualifier get automatically added on
every build? Documentation pointers welcome :)
On Thu, Jun 22, 2017 at 2:30 PM Neil Bartlett <nj...@gmail.com> wrote:
> We don't like to overload the version with information about release
> status, so no it's not exactly like maven. An artifact is a release simply
> if it is present in a designated Release repository.
>
> This enables a process where the artifact does not need to be rebuilt in
> order to release it. Rebuilding at such a late stage can lead to
> instability because small differences can creep in.
>
> Neil
>
> On 22 Jun 2017 8:23 p.m., "Justin Edelson" <ju...@justinedelson.com>
> wrote:
>
> > Neil-
> > Out of curiosity, in the bnd worldview you're describing, how is the
> > distinction between a snapshot and release denoted? Is it like Maven
> where
> > SNAPSHOT is used as a qualifier? Or is there some other convention?
> >
> > Thanks,
> > Justin
> >
> >
> > On Thu, Jun 22, 2017 at 1:51 PM Neil Bartlett <nj...@gmail.com>
> > wrote:
> >
> > > Are you sure that you’re actually *releasing* every day? Or do you only
> > > mean sending out snapshots?
> > >
> > > I agree with Justin that releases should be immutable, and that is what
> > > bnd and Bndtools have always tried to achieve. However bnd is not a
> > > complete end-to-end build system like Maven or Gradle, and Bndtools is
> > only
> > > an IDE, so we don’t get a lot of say in the larger process. You should
> > work
> > > within the conventions of whatever build tool you use.
> > >
> > > The process encouraged by bnd is very close to the Maven one. Once a
> > > release is made, you must not change it. If you change a package after
> a
> > > release, then you move up to a new version number for that package. You
> > can
> > > then build and publish as many snapshot of that new version number as
> you
> > > like, usually with a timestamp in the qualifier segment of the version.
> > > Once you release, that version is consumed and you go back to the
> > beginning
> > > of this paragraph.
> > >
> > > Neil
> > >
> > >
> > > > On 22 Jun 2017, at 18:12, Tom Quarendon <
> > > tom.quarendon@worldprogramming.com> wrote:
> > > >
> > > > The cadence is important I that if I want to "release" off the back
> of
> > > each build, I don't want to have to manually make a code modification
> > every
> > > day, nor do I want to have the build process modify the source code,
> that
> > > just doesn't seem right.
> > > >
> > > > I'm probably at odds with standard practice.
> > > >
> > > > -----Original Message-----
> > > > From: Justin Edelson [mailto:justin@justinedelson.com]
> > > > Sent: 22 June 2017 17:40
> > > > To: users@felix.apache.org
> > > > Subject: Re: API baselining with maven-bundle-plugin
> > > >
> > > > The cadence of releases is irrelevant. But each release must have a
> > > distinct (bundle) version number. Otherwise, the version loses any
> > meaning
> > > since two copies of "version 1.0.0" are not necessarily the same.
> > > >
> > > > If you only want to change the bundle version when you start changing
> > > the project, that's certainly a choice you can make. I find (and many
> > > others do
> > > > too) it easier to do this automatically at the time of release (i.e.
> > set
> > > the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't
> > get
> > > forgotten.
> > > >
> > > > I can't speak to how bndtools work. I assume it must do some kind of
> > > automatic bundle version management since it would be inappropriate to
> > have
> > > mutable releases.
> > > >
> > > >
> > > > On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
> > > tom.quarendon@worldprogramming.com> wrote:
> > > >
> > > >> I perhaps have a different concept of how things work. But I'm not
> > > >> very familiar with how maven works.
> > > >>
> > > >> Fundamentally, if I haven't changed any code, why have any of the
> > > >> version numbers changed? I'm perhaps viewing things from a
> continuous
> > > >> deployment perspective rather than a "release once a year"
> > perspective.
> > > >>
> > > >> As far as I can tell with bndtools, version numbers are changed as,
> > > >> and only as necessary.
> > > >> I check out the source code, and then as I change code, it prompts
> me
> > > >> to change package and bundle versions appropriately.
> > > >> Hence after my edits, the package and version numbers of things I
> > > >> haven't changed are the same as they were, which seems right to me.
> > > >> Things that I've changed have changed version package and bundle
> > > version numbers.
> > > >> If I then do a "mvn deploy" (well, "gradle release") on the result,
> > > >> then OK, the unchanged bundles will be re-released to the repository
> > > >> (or maybe not, maybe maven/gradle doesn't replace a bundle with one
> > > >> with the same version, don't know), but the contents are the same
> > > >> (from a source perspective anyhow), so that doesn't matter.
> > > >>
> > > >> As I say, I don't have much experience of using maven etc, I was
> > > >> confused that it worked in an apparently different way to bndtools,
> > > >> which is based on the same thing.
> > > >>
> > > >>
> > > >>
> > > >> -----Original Message-----
> > > >> From: Justin Edelson [mailto:justin@justinedelson.com]
> > > >> Sent: 22 June 2017 15:15
> > > >> To: users@felix.apache.org
> > > >> Subject: Re: API baselining with maven-bundle-plugin
> > > >>
> > > >> Hi,
> > > >> I think you might be mixing up the bundle version (what I think you
> > > >> are referring to as the "project version") with the package
> versions.
> > > >> baseline is larger concerned with the latter, and only uses the
> former
> > > >> to find the comparison version.
> > > >>
> > > >> Released versions should always be considered immutable, so you
> should
> > > >> *always* change the project version immediately after a release. If
> > > >> you use the maven-release-plugin, this is automatically done, but
> > > >> otherwise you would need to do this manually.
> > > >>
> > > >> Here's the way it is supposed to work:
> > > >>
> > > >> * You have a bundle with version 1.0.0 and package com.myco.foo at
> > > >> version 1.0.0. This bundle is deployed in some repository.
> > > >> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> > > >> 1.0.1-SNAPSHOT in Maven terms).
> > > >> * You make some change to one of the classes/interfaces in
> > com.myco.foo.
> > > >> * Then you run the baseline plugin. Baseline compares the current
> > > >> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
> > > >> checks each exported package. It sees that there has been some
> change
> > > >> in com.myco.foo which requires that the package version change. It
> > > >> then alerts you to this change and recommends a new package version
> > > >> number. Alternatively, if you changed the exported package version,
> > > >> baseline will still tell you that there was a change made but that
> you
> > > >> have already correctly changed the package version number.
> > > >>
> > > >> HTH,
> > > >> Justin
> > > >>
> > > >> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> > > >> tom.quarendon@worldprogramming.com> 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.
> > > >>>
> > > >>
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> > >
> > >
> >
>
Re: API baselining with maven-bundle-plugin
Posted by Neil Bartlett <nj...@gmail.com>.
We don't like to overload the version with information about release
status, so no it's not exactly like maven. An artifact is a release simply
if it is present in a designated Release repository.
This enables a process where the artifact does not need to be rebuilt in
order to release it. Rebuilding at such a late stage can lead to
instability because small differences can creep in.
Neil
On 22 Jun 2017 8:23 p.m., "Justin Edelson" <ju...@justinedelson.com> wrote:
> Neil-
> Out of curiosity, in the bnd worldview you're describing, how is the
> distinction between a snapshot and release denoted? Is it like Maven where
> SNAPSHOT is used as a qualifier? Or is there some other convention?
>
> Thanks,
> Justin
>
>
> On Thu, Jun 22, 2017 at 1:51 PM Neil Bartlett <nj...@gmail.com>
> wrote:
>
> > Are you sure that you’re actually *releasing* every day? Or do you only
> > mean sending out snapshots?
> >
> > I agree with Justin that releases should be immutable, and that is what
> > bnd and Bndtools have always tried to achieve. However bnd is not a
> > complete end-to-end build system like Maven or Gradle, and Bndtools is
> only
> > an IDE, so we don’t get a lot of say in the larger process. You should
> work
> > within the conventions of whatever build tool you use.
> >
> > The process encouraged by bnd is very close to the Maven one. Once a
> > release is made, you must not change it. If you change a package after a
> > release, then you move up to a new version number for that package. You
> can
> > then build and publish as many snapshot of that new version number as you
> > like, usually with a timestamp in the qualifier segment of the version.
> > Once you release, that version is consumed and you go back to the
> beginning
> > of this paragraph.
> >
> > Neil
> >
> >
> > > On 22 Jun 2017, at 18:12, Tom Quarendon <
> > tom.quarendon@worldprogramming.com> wrote:
> > >
> > > The cadence is important I that if I want to "release" off the back of
> > each build, I don't want to have to manually make a code modification
> every
> > day, nor do I want to have the build process modify the source code, that
> > just doesn't seem right.
> > >
> > > I'm probably at odds with standard practice.
> > >
> > > -----Original Message-----
> > > From: Justin Edelson [mailto:justin@justinedelson.com]
> > > Sent: 22 June 2017 17:40
> > > To: users@felix.apache.org
> > > Subject: Re: API baselining with maven-bundle-plugin
> > >
> > > The cadence of releases is irrelevant. But each release must have a
> > distinct (bundle) version number. Otherwise, the version loses any
> meaning
> > since two copies of "version 1.0.0" are not necessarily the same.
> > >
> > > If you only want to change the bundle version when you start changing
> > the project, that's certainly a choice you can make. I find (and many
> > others do
> > > too) it easier to do this automatically at the time of release (i.e.
> set
> > the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't
> get
> > forgotten.
> > >
> > > I can't speak to how bndtools work. I assume it must do some kind of
> > automatic bundle version management since it would be inappropriate to
> have
> > mutable releases.
> > >
> > >
> > > On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
> > tom.quarendon@worldprogramming.com> wrote:
> > >
> > >> I perhaps have a different concept of how things work. But I'm not
> > >> very familiar with how maven works.
> > >>
> > >> Fundamentally, if I haven't changed any code, why have any of the
> > >> version numbers changed? I'm perhaps viewing things from a continuous
> > >> deployment perspective rather than a "release once a year"
> perspective.
> > >>
> > >> As far as I can tell with bndtools, version numbers are changed as,
> > >> and only as necessary.
> > >> I check out the source code, and then as I change code, it prompts me
> > >> to change package and bundle versions appropriately.
> > >> Hence after my edits, the package and version numbers of things I
> > >> haven't changed are the same as they were, which seems right to me.
> > >> Things that I've changed have changed version package and bundle
> > version numbers.
> > >> If I then do a "mvn deploy" (well, "gradle release") on the result,
> > >> then OK, the unchanged bundles will be re-released to the repository
> > >> (or maybe not, maybe maven/gradle doesn't replace a bundle with one
> > >> with the same version, don't know), but the contents are the same
> > >> (from a source perspective anyhow), so that doesn't matter.
> > >>
> > >> As I say, I don't have much experience of using maven etc, I was
> > >> confused that it worked in an apparently different way to bndtools,
> > >> which is based on the same thing.
> > >>
> > >>
> > >>
> > >> -----Original Message-----
> > >> From: Justin Edelson [mailto:justin@justinedelson.com]
> > >> Sent: 22 June 2017 15:15
> > >> To: users@felix.apache.org
> > >> Subject: Re: API baselining with maven-bundle-plugin
> > >>
> > >> Hi,
> > >> I think you might be mixing up the bundle version (what I think you
> > >> are referring to as the "project version") with the package versions.
> > >> baseline is larger concerned with the latter, and only uses the former
> > >> to find the comparison version.
> > >>
> > >> Released versions should always be considered immutable, so you should
> > >> *always* change the project version immediately after a release. If
> > >> you use the maven-release-plugin, this is automatically done, but
> > >> otherwise you would need to do this manually.
> > >>
> > >> Here's the way it is supposed to work:
> > >>
> > >> * You have a bundle with version 1.0.0 and package com.myco.foo at
> > >> version 1.0.0. This bundle is deployed in some repository.
> > >> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> > >> 1.0.1-SNAPSHOT in Maven terms).
> > >> * You make some change to one of the classes/interfaces in
> com.myco.foo.
> > >> * Then you run the baseline plugin. Baseline compares the current
> > >> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
> > >> checks each exported package. It sees that there has been some change
> > >> in com.myco.foo which requires that the package version change. It
> > >> then alerts you to this change and recommends a new package version
> > >> number. Alternatively, if you changed the exported package version,
> > >> baseline will still tell you that there was a change made but that you
> > >> have already correctly changed the package version number.
> > >>
> > >> HTH,
> > >> Justin
> > >>
> > >> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> > >> tom.quarendon@worldprogramming.com> 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.
> > >>>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
> >
> >
>
Re: API baselining with maven-bundle-plugin
Posted by Justin Edelson <ju...@justinedelson.com>.
Neil-
Out of curiosity, in the bnd worldview you're describing, how is the
distinction between a snapshot and release denoted? Is it like Maven where
SNAPSHOT is used as a qualifier? Or is there some other convention?
Thanks,
Justin
On Thu, Jun 22, 2017 at 1:51 PM Neil Bartlett <nj...@gmail.com> wrote:
> Are you sure that you’re actually *releasing* every day? Or do you only
> mean sending out snapshots?
>
> I agree with Justin that releases should be immutable, and that is what
> bnd and Bndtools have always tried to achieve. However bnd is not a
> complete end-to-end build system like Maven or Gradle, and Bndtools is only
> an IDE, so we don’t get a lot of say in the larger process. You should work
> within the conventions of whatever build tool you use.
>
> The process encouraged by bnd is very close to the Maven one. Once a
> release is made, you must not change it. If you change a package after a
> release, then you move up to a new version number for that package. You can
> then build and publish as many snapshot of that new version number as you
> like, usually with a timestamp in the qualifier segment of the version.
> Once you release, that version is consumed and you go back to the beginning
> of this paragraph.
>
> Neil
>
>
> > On 22 Jun 2017, at 18:12, Tom Quarendon <
> tom.quarendon@worldprogramming.com> wrote:
> >
> > The cadence is important I that if I want to "release" off the back of
> each build, I don't want to have to manually make a code modification every
> day, nor do I want to have the build process modify the source code, that
> just doesn't seem right.
> >
> > I'm probably at odds with standard practice.
> >
> > -----Original Message-----
> > From: Justin Edelson [mailto:justin@justinedelson.com]
> > Sent: 22 June 2017 17:40
> > To: users@felix.apache.org
> > Subject: Re: API baselining with maven-bundle-plugin
> >
> > The cadence of releases is irrelevant. But each release must have a
> distinct (bundle) version number. Otherwise, the version loses any meaning
> since two copies of "version 1.0.0" are not necessarily the same.
> >
> > If you only want to change the bundle version when you start changing
> the project, that's certainly a choice you can make. I find (and many
> others do
> > too) it easier to do this automatically at the time of release (i.e. set
> the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't get
> forgotten.
> >
> > I can't speak to how bndtools work. I assume it must do some kind of
> automatic bundle version management since it would be inappropriate to have
> mutable releases.
> >
> >
> > On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
> tom.quarendon@worldprogramming.com> wrote:
> >
> >> I perhaps have a different concept of how things work. But I'm not
> >> very familiar with how maven works.
> >>
> >> Fundamentally, if I haven't changed any code, why have any of the
> >> version numbers changed? I'm perhaps viewing things from a continuous
> >> deployment perspective rather than a "release once a year" perspective.
> >>
> >> As far as I can tell with bndtools, version numbers are changed as,
> >> and only as necessary.
> >> I check out the source code, and then as I change code, it prompts me
> >> to change package and bundle versions appropriately.
> >> Hence after my edits, the package and version numbers of things I
> >> haven't changed are the same as they were, which seems right to me.
> >> Things that I've changed have changed version package and bundle
> version numbers.
> >> If I then do a "mvn deploy" (well, "gradle release") on the result,
> >> then OK, the unchanged bundles will be re-released to the repository
> >> (or maybe not, maybe maven/gradle doesn't replace a bundle with one
> >> with the same version, don't know), but the contents are the same
> >> (from a source perspective anyhow), so that doesn't matter.
> >>
> >> As I say, I don't have much experience of using maven etc, I was
> >> confused that it worked in an apparently different way to bndtools,
> >> which is based on the same thing.
> >>
> >>
> >>
> >> -----Original Message-----
> >> From: Justin Edelson [mailto:justin@justinedelson.com]
> >> Sent: 22 June 2017 15:15
> >> To: users@felix.apache.org
> >> Subject: Re: API baselining with maven-bundle-plugin
> >>
> >> Hi,
> >> I think you might be mixing up the bundle version (what I think you
> >> are referring to as the "project version") with the package versions.
> >> baseline is larger concerned with the latter, and only uses the former
> >> to find the comparison version.
> >>
> >> Released versions should always be considered immutable, so you should
> >> *always* change the project version immediately after a release. If
> >> you use the maven-release-plugin, this is automatically done, but
> >> otherwise you would need to do this manually.
> >>
> >> Here's the way it is supposed to work:
> >>
> >> * You have a bundle with version 1.0.0 and package com.myco.foo at
> >> version 1.0.0. This bundle is deployed in some repository.
> >> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> >> 1.0.1-SNAPSHOT in Maven terms).
> >> * You make some change to one of the classes/interfaces in com.myco.foo.
> >> * Then you run the baseline plugin. Baseline compares the current
> >> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
> >> checks each exported package. It sees that there has been some change
> >> in com.myco.foo which requires that the package version change. It
> >> then alerts you to this change and recommends a new package version
> >> number. Alternatively, if you changed the exported package version,
> >> baseline will still tell you that there was a change made but that you
> >> have already correctly changed the package version number.
> >>
> >> HTH,
> >> Justin
> >>
> >> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> >> tom.quarendon@worldprogramming.com> 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.
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> > For additional commands, e-mail: users-help@felix.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: API baselining with maven-bundle-plugin
Posted by Neil Bartlett <nj...@gmail.com>.
Are you sure that you’re actually *releasing* every day? Or do you only mean sending out snapshots?
I agree with Justin that releases should be immutable, and that is what bnd and Bndtools have always tried to achieve. However bnd is not a complete end-to-end build system like Maven or Gradle, and Bndtools is only an IDE, so we don’t get a lot of say in the larger process. You should work within the conventions of whatever build tool you use.
The process encouraged by bnd is very close to the Maven one. Once a release is made, you must not change it. If you change a package after a release, then you move up to a new version number for that package. You can then build and publish as many snapshot of that new version number as you like, usually with a timestamp in the qualifier segment of the version. Once you release, that version is consumed and you go back to the beginning of this paragraph.
Neil
> On 22 Jun 2017, at 18:12, Tom Quarendon <to...@worldprogramming.com> wrote:
>
> The cadence is important I that if I want to "release" off the back of each build, I don't want to have to manually make a code modification every day, nor do I want to have the build process modify the source code, that just doesn't seem right.
>
> I'm probably at odds with standard practice.
>
> -----Original Message-----
> From: Justin Edelson [mailto:justin@justinedelson.com]
> Sent: 22 June 2017 17:40
> To: users@felix.apache.org
> Subject: Re: API baselining with maven-bundle-plugin
>
> The cadence of releases is irrelevant. But each release must have a distinct (bundle) version number. Otherwise, the version loses any meaning since two copies of "version 1.0.0" are not necessarily the same.
>
> If you only want to change the bundle version when you start changing the project, that's certainly a choice you can make. I find (and many others do
> too) it easier to do this automatically at the time of release (i.e. set the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't get forgotten.
>
> I can't speak to how bndtools work. I assume it must do some kind of automatic bundle version management since it would be inappropriate to have mutable releases.
>
>
> On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon < tom.quarendon@worldprogramming.com> wrote:
>
>> I perhaps have a different concept of how things work. But I'm not
>> very familiar with how maven works.
>>
>> Fundamentally, if I haven't changed any code, why have any of the
>> version numbers changed? I'm perhaps viewing things from a continuous
>> deployment perspective rather than a "release once a year" perspective.
>>
>> As far as I can tell with bndtools, version numbers are changed as,
>> and only as necessary.
>> I check out the source code, and then as I change code, it prompts me
>> to change package and bundle versions appropriately.
>> Hence after my edits, the package and version numbers of things I
>> haven't changed are the same as they were, which seems right to me.
>> Things that I've changed have changed version package and bundle version numbers.
>> If I then do a "mvn deploy" (well, "gradle release") on the result,
>> then OK, the unchanged bundles will be re-released to the repository
>> (or maybe not, maybe maven/gradle doesn't replace a bundle with one
>> with the same version, don't know), but the contents are the same
>> (from a source perspective anyhow), so that doesn't matter.
>>
>> As I say, I don't have much experience of using maven etc, I was
>> confused that it worked in an apparently different way to bndtools,
>> which is based on the same thing.
>>
>>
>>
>> -----Original Message-----
>> From: Justin Edelson [mailto:justin@justinedelson.com]
>> Sent: 22 June 2017 15:15
>> To: users@felix.apache.org
>> Subject: Re: API baselining with maven-bundle-plugin
>>
>> Hi,
>> I think you might be mixing up the bundle version (what I think you
>> are referring to as the "project version") with the package versions.
>> baseline is larger concerned with the latter, and only uses the former
>> to find the comparison version.
>>
>> Released versions should always be considered immutable, so you should
>> *always* change the project version immediately after a release. If
>> you use the maven-release-plugin, this is automatically done, but
>> otherwise you would need to do this manually.
>>
>> Here's the way it is supposed to work:
>>
>> * You have a bundle with version 1.0.0 and package com.myco.foo at
>> version 1.0.0. This bundle is deployed in some repository.
>> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
>> 1.0.1-SNAPSHOT in Maven terms).
>> * You make some change to one of the classes/interfaces in com.myco.foo.
>> * Then you run the baseline plugin. Baseline compares the current
>> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
>> checks each exported package. It sees that there has been some change
>> in com.myco.foo which requires that the package version change. It
>> then alerts you to this change and recommends a new package version
>> number. Alternatively, if you changed the exported package version,
>> baseline will still tell you that there was a change made but that you
>> have already correctly changed the package version number.
>>
>> HTH,
>> Justin
>>
>> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
>> tom.quarendon@worldprogramming.com> 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.
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
RE: API baselining with maven-bundle-plugin
Posted by Tom Quarendon <to...@worldprogramming.com>.
The cadence is important I that if I want to "release" off the back of each build, I don't want to have to manually make a code modification every day, nor do I want to have the build process modify the source code, that just doesn't seem right.
I'm probably at odds with standard practice.
-----Original Message-----
From: Justin Edelson [mailto:justin@justinedelson.com]
Sent: 22 June 2017 17:40
To: users@felix.apache.org
Subject: Re: API baselining with maven-bundle-plugin
The cadence of releases is irrelevant. But each release must have a distinct (bundle) version number. Otherwise, the version loses any meaning since two copies of "version 1.0.0" are not necessarily the same.
If you only want to change the bundle version when you start changing the project, that's certainly a choice you can make. I find (and many others do
too) it easier to do this automatically at the time of release (i.e. set the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't get forgotten.
I can't speak to how bndtools work. I assume it must do some kind of automatic bundle version management since it would be inappropriate to have mutable releases.
On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon < tom.quarendon@worldprogramming.com> wrote:
> I perhaps have a different concept of how things work. But I'm not
> very familiar with how maven works.
>
> Fundamentally, if I haven't changed any code, why have any of the
> version numbers changed? I'm perhaps viewing things from a continuous
> deployment perspective rather than a "release once a year" perspective.
>
> As far as I can tell with bndtools, version numbers are changed as,
> and only as necessary.
> I check out the source code, and then as I change code, it prompts me
> to change package and bundle versions appropriately.
> Hence after my edits, the package and version numbers of things I
> haven't changed are the same as they were, which seems right to me.
> Things that I've changed have changed version package and bundle version numbers.
> If I then do a "mvn deploy" (well, "gradle release") on the result,
> then OK, the unchanged bundles will be re-released to the repository
> (or maybe not, maybe maven/gradle doesn't replace a bundle with one
> with the same version, don't know), but the contents are the same
> (from a source perspective anyhow), so that doesn't matter.
>
> As I say, I don't have much experience of using maven etc, I was
> confused that it worked in an apparently different way to bndtools,
> which is based on the same thing.
>
>
>
> -----Original Message-----
> From: Justin Edelson [mailto:justin@justinedelson.com]
> Sent: 22 June 2017 15:15
> To: users@felix.apache.org
> Subject: Re: API baselining with maven-bundle-plugin
>
> Hi,
> I think you might be mixing up the bundle version (what I think you
> are referring to as the "project version") with the package versions.
> baseline is larger concerned with the latter, and only uses the former
> to find the comparison version.
>
> Released versions should always be considered immutable, so you should
> *always* change the project version immediately after a release. If
> you use the maven-release-plugin, this is automatically done, but
> otherwise you would need to do this manually.
>
> Here's the way it is supposed to work:
>
> * You have a bundle with version 1.0.0 and package com.myco.foo at
> version 1.0.0. This bundle is deployed in some repository.
> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> 1.0.1-SNAPSHOT in Maven terms).
> * You make some change to one of the classes/interfaces in com.myco.foo.
> * Then you run the baseline plugin. Baseline compares the current
> state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and
> checks each exported package. It sees that there has been some change
> in com.myco.foo which requires that the package version change. It
> then alerts you to this change and recommends a new package version
> number. Alternatively, if you changed the exported package version,
> baseline will still tell you that there was a change made but that you
> have already correctly changed the package version number.
>
> HTH,
> Justin
>
> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> tom.quarendon@worldprogramming.com> 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.
> >
>
Re: API baselining with maven-bundle-plugin
Posted by Justin Edelson <ju...@justinedelson.com>.
The cadence of releases is irrelevant. But each release must have a
distinct (bundle) version number. Otherwise, the version loses any meaning
since two copies of "version 1.0.0" are not necessarily the same.
If you only want to change the bundle version when you start changing the
project, that's certainly a choice you can make. I find (and many others do
too) it easier to do this automatically at the time of release (i.e. set
the master/trunk version to lastversion+1-SNAPSHOT) so that it doesn't get
forgotten.
I can't speak to how bndtools work. I assume it must do some kind of
automatic bundle version management since it would be inappropriate to have
mutable releases.
On Thu, Jun 22, 2017 at 11:58 AM Tom Quarendon <
tom.quarendon@worldprogramming.com> wrote:
> I perhaps have a different concept of how things work. But I'm not very
> familiar with how maven works.
>
> Fundamentally, if I haven't changed any code, why have any of the version
> numbers changed? I'm perhaps viewing things from a continuous deployment
> perspective rather than a "release once a year" perspective.
>
> As far as I can tell with bndtools, version numbers are changed as, and
> only as necessary.
> I check out the source code, and then as I change code, it prompts me to
> change package and bundle versions appropriately.
> Hence after my edits, the package and version numbers of things I haven't
> changed are the same as they were, which seems right to me. Things that
> I've changed have changed version package and bundle version numbers.
> If I then do a "mvn deploy" (well, "gradle release") on the result, then
> OK, the unchanged bundles will be re-released to the repository (or maybe
> not, maybe maven/gradle doesn't replace a bundle with one with the same
> version, don't know), but the contents are the same (from a source
> perspective anyhow), so that doesn't matter.
>
> As I say, I don't have much experience of using maven etc, I was confused
> that it worked in an apparently different way to bndtools, which is based
> on the same thing.
>
>
>
> -----Original Message-----
> From: Justin Edelson [mailto:justin@justinedelson.com]
> Sent: 22 June 2017 15:15
> To: users@felix.apache.org
> Subject: Re: API baselining with maven-bundle-plugin
>
> Hi,
> I think you might be mixing up the bundle version (what I think you are
> referring to as the "project version") with the package versions. baseline
> is larger concerned with the latter, and only uses the former to find the
> comparison version.
>
> Released versions should always be considered immutable, so you should
> *always* change the project version immediately after a release. If you
> use the maven-release-plugin, this is automatically done, but otherwise you
> would need to do this manually.
>
> Here's the way it is supposed to work:
>
> * You have a bundle with version 1.0.0 and package com.myco.foo at version
> 1.0.0. This bundle is deployed in some repository.
> * The current version of the bundle is now 1.0.1.SNAPSHOT (or
> 1.0.1-SNAPSHOT in Maven terms).
> * You make some change to one of the classes/interfaces in com.myco.foo.
> * Then you run the baseline plugin. Baseline compares the current state
> against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and checks each
> exported package. It sees that there has been some change in com.myco.foo
> which requires that the package version change. It then alerts you to this
> change and recommends a new package version number. Alternatively, if you
> changed the exported package version, baseline will still tell you that
> there was a change made but that you have already correctly changed the
> package version number.
>
> HTH,
> Justin
>
> On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
> tom.quarendon@worldprogramming.com> 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.
> >
>
RE: API baselining with maven-bundle-plugin
Posted by Tom Quarendon <to...@worldprogramming.com>.
I perhaps have a different concept of how things work. But I'm not very familiar with how maven works.
Fundamentally, if I haven't changed any code, why have any of the version numbers changed? I'm perhaps viewing things from a continuous deployment perspective rather than a "release once a year" perspective.
As far as I can tell with bndtools, version numbers are changed as, and only as necessary.
I check out the source code, and then as I change code, it prompts me to change package and bundle versions appropriately.
Hence after my edits, the package and version numbers of things I haven't changed are the same as they were, which seems right to me. Things that I've changed have changed version package and bundle version numbers.
If I then do a "mvn deploy" (well, "gradle release") on the result, then OK, the unchanged bundles will be re-released to the repository (or maybe not, maybe maven/gradle doesn't replace a bundle with one with the same version, don't know), but the contents are the same (from a source perspective anyhow), so that doesn't matter.
As I say, I don't have much experience of using maven etc, I was confused that it worked in an apparently different way to bndtools, which is based on the same thing.
-----Original Message-----
From: Justin Edelson [mailto:justin@justinedelson.com]
Sent: 22 June 2017 15:15
To: users@felix.apache.org
Subject: Re: API baselining with maven-bundle-plugin
Hi,
I think you might be mixing up the bundle version (what I think you are referring to as the "project version") with the package versions. baseline is larger concerned with the latter, and only uses the former to find the comparison version.
Released versions should always be considered immutable, so you should
*always* change the project version immediately after a release. If you use the maven-release-plugin, this is automatically done, but otherwise you would need to do this manually.
Here's the way it is supposed to work:
* You have a bundle with version 1.0.0 and package com.myco.foo at version 1.0.0. This bundle is deployed in some repository.
* The current version of the bundle is now 1.0.1.SNAPSHOT (or 1.0.1-SNAPSHOT in Maven terms).
* You make some change to one of the classes/interfaces in com.myco.foo.
* Then you run the baseline plugin. Baseline compares the current state against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and checks each exported package. It sees that there has been some change in com.myco.foo which requires that the package version change. It then alerts you to this change and recommends a new package version number. Alternatively, if you changed the exported package version, baseline will still tell you that there was a change made but that you have already correctly changed the package version number.
HTH,
Justin
On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon < tom.quarendon@worldprogramming.com> 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.
>
Re: API baselining with maven-bundle-plugin
Posted by Justin Edelson <ju...@justinedelson.com>.
Hi,
I think you might be mixing up the bundle version (what I think you are
referring to as the "project version") with the package versions. baseline
is larger concerned with the latter, and only uses the former to find the
comparison version.
Released versions should always be considered immutable, so you should
*always* change the project version immediately after a release. If you use
the maven-release-plugin, this is automatically done, but otherwise you
would need to do this manually.
Here's the way it is supposed to work:
* You have a bundle with version 1.0.0 and package com.myco.foo at version
1.0.0. This bundle is deployed in some repository.
* The current version of the bundle is now 1.0.1.SNAPSHOT (or
1.0.1-SNAPSHOT in Maven terms).
* You make some change to one of the classes/interfaces in com.myco.foo.
* Then you run the baseline plugin. Baseline compares the current state
against the last release (so 1.0.1.SNAPSHOT vs. 1.0.0) and checks each
exported package. It sees that there has been some change in com.myco.foo
which requires that the package version change. It then alerts you to this
change and recommends a new package version number. Alternatively, if you
changed the exported package version, baseline will still tell you that
there was a change made but that you have already correctly changed the
package version number.
HTH,
Justin
On Thu, Jun 22, 2017 at 10:02 AM Tom Quarendon <
tom.quarendon@worldprogramming.com> 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.
>
Re: API baselining with maven-bundle-plugin
Posted by Christian Schneider <ch...@die-schneider.net>.
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:cschneider111@gmail.com] On Behalf Of Christian Schneider
> Sent: 22 June 2017 17:07
> To: Tom Quarendon <to...@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-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org