felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Milen Dyankov <milendyan...@gmail.com>
Subject Re: API baselining with maven-bundle-plugin
Date Fri, 23 Jun 2017 17:54:11 GMT
>
> 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 <njbartlett@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message