Afaik, the maven release plugin can actually release several maven projects at the same time each one having its own release number. Meaning when you release a project consisting of several maven subprojects, each one can have its own release version (whether or not that's desirable is a completely different problem).
On the osgi versioning problem, I'm not sure we have to assume that the version number of the package is the same as the one for the bundle, so the fact you need to specify a range isn't related to the release process. The maven bundle plugin can automatically generate a range based on the information it finds, so here again, it's related to the package versioning, not the bundle versioning. Please remember that the semantic associated to the version in OSGi is at the package level, not the bundle level. Last, I'm not sure we're going into the right direction. I think those decisions should not be bound to technical considerations so early in the process. I'm quite sure we have a lot of freedom in choosing how we want to version things and release them. Maybe we should start by stating by agreeing on what we'd like first. On Fri, Feb 4, 2011 at 13:18, zoe slattery <[email protected]> wrote: > On 03/02/2011 22:28, Guillaume Nodet wrote: >> >> What kind of experiments do you have in mind ? > > Probably this is more to do with my understanding (or lack of) of the way in > which the current maven > build specifies versions and how the release process deals with them. >> >> I'm not sure to actually understand how the release process will be >> different if we release everyting in one go, component by component, >> or bundle by bundle. At the end, it always comes down to the same >> steps: updating pom dependencies, mvn release:prepare release:perform, >> updating jira, vote, updating the web site, annoucement. >> The obvious different will be at which level you run the command from, >> but apart from that, I kinda fail to see what kind of impact it would >> have. > > The aim is to keep the release process the same, as you say. To take a > specific example, I was looking at the quiesce module, the sort of thing > that the pom.xml would need to indicate is: > > 1) Quiesce module depends on released versions of parent, testsupport, util > (this is easy) > 2) Quiesce module depends on a released version of the quiesce api (one of > the agregator's sub-modules) but development versions of the implementation > sub-modules. > > At the moment to make step 2 work it's necessary to override the default > package imports for, say, the quiesce manager implementation and comment > out quiesce-api in the modules section. After that I get something which > builds and runs - the quiesce manager implementation bundle has the correct > package imports. I've checked in the quiesce pom (with debug in it). I'm not > quite sure what the release process will do with this, so I need to check. > > > Zoe > > >> On Thu, Feb 3, 2011 at 16:11,<[email protected]> wrote: >>> >>> Author: zoe >>> Date: Thu Feb 3 15:11:33 2011 >>> New Revision: 1066827 >>> >>> URL: http://svn.apache.org/viewvc?rev=1066827&view=rev >>> Log: >>> recreating with 0.4 from trunk >>> >>> Added: >>> aries/branches/experimental-release-by-module/ >>> - copied from r1066825, aries/trunk/ >>> >>> >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
