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:jus...@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.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." > 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: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
