On Fri, Feb 4, 2011 at 23:41, Alasdair Nottingham <[email protected]> wrote: > > > Alasdair Nottingham > > On 4 Feb 2011, at 22:13, Felix Meschberger <[email protected]> wrote: > >> Hi, >> >> Am Freitag, den 04.02.2011, 21:33 +0000 schrieb Alasdair Nottingham: >>> Hi, >>> >>> Currently we specify versions of exported packages in the pom. This is >>> not ideal as it means whenever anyone makes a change in a package they >>> have to edit the pom, >> >> You could argue that modifying exported packages is critical, so making >> it harder to do might get people to think twice ... Granted this is kind >> of a weak argument ;-) >> > > In fact I want it to be easy, the easier the better. If you change the code > the version should increment.
So why even bother with having to manually change the version ? I think it should be possible to have the maven-bundle-plugin increment the version depending on the kind of changes by comparing the package signatures and make sure it follows the semantic versioning. Given it has already been done (see https://www.assembla.com/wiki/show/obcc/OSGi_Version_Generator) I think we could add that to the maven bundle plugin. However, there's something which is worrying me about the semantic versioning. I don't think it can cope with maintenance branches. The process of incrementing a package version works well in a single line of releases, but not in a tree, so can't ever release a package which doesn't contain all the previous changes. Or rather the process works for a given package, but the problem is that our bundles do not only contain a single package. Let's take a concrete example. I have a bundle version 3.0 which has two packages foo / 1.0 + bar / 1.0. In a future release 3.1 of that bundle, i add one functionality to the foo package and a minor modification to the bar package, so I release this with foo / 1.1 + bar / 1.0.1. Some time later, I find a bug in the bar package which I'd like to fix for both minor versions of my bundle. If I do so, I'd end up with a bundle 3.0.1 with foo / 1.0 + bar / 1.0.1 and a bundle 3.1.1 with foo / 1.1 + bar / 1.0.2. That's not really possible because the two bar / 1.0.1 package would be different. Possible solutions: * backport into 3.0 branch the change that modification that caused the bump from 1.0 to 1.0.1 (when releasing 3.1). However, this may not be a big fix, maybe a small improvement that I don't want to backport, so I don't think this solution is a good idea * never release a bundle which exports multiple packages: that sucks too * don't do maintenance release: i don't think we want that * consider that any modification you may not want to backport in a maintenance branch later should lead to bump the minor version of a package, even if the signature of the package doesn't really change I think the last one is the only one applicable. Thoughts ? >> On the other hand, the problem is always the same: you have to update >> information in a secondary location -- regardless of whether this is the >> packaginfo or the pom.xml file. >> > > Right, and packageinfo is right next to the classes you just updated, closer > = better IMHO. > >> The advantage of doing it in the pom.xml file IMHO is that you have a >> complete overview of your exports incl. their versions. YMMV. >> > > The downside in our case is you have to update the bundle and the uber > bundle, bigger chance of getting out of sync, which would be very very bad. > >>> also you need to sync the version correctly >>> between the bundles >> >> the bundle plugin takes care of this (fortunately) -- assuming you mean >> the "Import-Package" versioning. >> > > I'm trying to address export bundle. I'm happy with the import package stuff. > >>> and the uber bundles. >> >>> >>> bnd supports the packageinfo files (and also annotations in >>> package-info.java), but those are not currently picked up and used in >>> our build. I raise FELIX-2819 and a workaround has been suggested, >>> which I managed to get working. >>> >>> The fix would be to add the following to the default-pom and get the >>> modules to use the updated parent: >>> >>> <resource> >>> <directory>${project.build.sourceDirectory}</directory> >>> <includes> >>> <include>**/packageinfo</include> >>> </includes> >>> </resource> >> >> Unfortunately, you will still have the regular resources in the >> src/main/resources tree. So you have to explicitly list this to in the >> <resources> element of the parent POM to not miss these... > > Right, this is already in our parent pom, so I'm proposing adding this in > addition to the other resources statements already there. > >> >> In Sling we currently maintain the exported package version in the POMs. >> This works fine but is also kind of suboptimal. >> >> I think the most important thing is to make it consistent: Do it either >> way, but stick to. > > I agree. I think we should use packageinfo though :) > >> >> Regards >> Felix >> >>> >>> Thoughts? >>> Alasdair >>> >> >> > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
