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 > <tom.quaren...@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:njbartl...@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.quaren...@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:jus...@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.quaren...@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:jus...@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.quaren...@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-unsubscr...@felix.apache.org >> For additional commands, e-mail: users-h...@felix.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@felix.apache.org > For additional commands, e-mail: users-h...@felix.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
