> > 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 <njbartl...@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: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.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: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 > > -- http://about.me/milen
