This is very different from what we have I think, as gogo's root pom isn't used at all. Releasing gogo involves releasing each of the maven subproject independantly afaik.
The main difference is that all felix releases consists of a *single* bundle. If we go this way, that would mean that releasing blueprint only would require 13 releases. Some of those just contain tests, so that does not make sense to me. From an usability point of view, I would definitely not go that way. I'd personaly rather go in the opposite direction and use a single reactor / release for all components. Another consideration is that I think we should tie the release cycle with the svn layout, i.e. if we want to keep each component with a separate lifecycle, we should have multiple trunks. That's way cleaner imho (and much more git friendly btw). On Tue, Feb 1, 2011 at 15:25, zoe slattery <[email protected]> wrote: > Hi Felix > > I had a look at felix to see if I could work out how you do the independent > releases. I didn't look through absolutely everything but > I only found two modules that had sub-modules (gogo and http). Of those two > it looks as though the pom structure in gogo might be similar > to what we need in Aries. Is this a model you would recommend? Or is there > something closer? > > Zoe >> >> Hi, >> >> Am Montag, den 31.01.2011, 15:22 +0100 schrieb Guillaume Nodet: >>> >>> Wouldn't that imply that each bundle has its own lifecycle ? >>> I think a while ago we agreed on having one release per "component", >>> i.e. blueprint (which includes api + core + cm + ...). >>> I'm not sure how well this would go if we have blueprint-core >>> 0.4.0-SNAPSHOT depending on blueprint-api-0.3.0. >> >> I bet you won't release blueprint-api as version 0.4.0 if it is the same >> as 0.3.0, right ? >> >> Regards >> Felix >> >>> > From a users point of view, it certainly does not help because all the >>> maven transitive dependencies are kinda screwed. >>> >>> On Mon, Jan 31, 2011 at 15:11, Felix Meschberger<[email protected]> >>> wrote: >>>> >>>> Hi, >>>> >>>> Am Montag, den 31.01.2011, 13:59 +0000 schrieb Jeremy Hughes: >>>>>>> >>>>>>> (c) Where an Aries module depends on other Aries modules, it will >>>>>>> depend >>>>>>> on the released versions of the other modules _until_ it requires a >>>>>>> change in the module that it depends on, at which stage it will >>>>>>> switch >>>>>>> to a dependency on the development version. >>>>>>> So for example, Blueprint 0.4-SNAPSHOT will depend on quiesce 0.3, >>>>>>> proxy >>>>>>> 0.3, testsupport 0.3 and parent 0.3. If blueprint 0.4-SNAPSHOT needs >>>>>>> to >>>>>>> pick up a change in proxy the blueprint top level pom will need to be >>>>>>> modified to point to proxy 0.4-SNAPSHOT. >>>>>> >>>>>> I would assume this means "depends on modified API" and does not mean >>>>>> "depends on some bug fixed in the implementation", right ? >>>>> >>>>> If you're referring to the semantic meaning attached to moving from >>>>> 0.3 to 0.4 then I think that would be taking this discussion in a >>>>> different direction. But that is a good point. Before getting into a >>>>> semantic versioning discussion, I think the intent of this was to so >>>>> if there are broken tests in 0.4-SNAPSHOT of a module which are fixed >>>>> by pulling in 0.4-SNAPSHOT of its dependency then its dependency >>>>> should be updated. >>>> >>>> No, this is not about semantic versioning (yet). >>>> >>>> This is about the following: Consider bundle X depends on the API >>>> org.apache.aries.y.api of bundle Y. Now some implementation of this API >>>> in package org.apache.aries.y.impl of bundle Y has a bug which must be >>>> fixed. In this case the dependency of bundle X on Y should not be >>>> changed. >>>> >>>> Regards >>>> Felix >>>> >>>> >>>>>> Regards >>>>>> Felix >>>>>> >>>>>>> This will lead us towards being able to release by module but it >>>>>>> implies >>>>>>> a change in development practice. I will make the pom changes locally >>>>>>> and test them but I'd like to check that release-by-module is still >>>>>>> the >>>>>>> goal and that you all think this is a reasonable way to be able to >>>>>>> achieve it. >>>>>>> >>>>>>> >>>>>>> Zoë >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>> >>>> >>> >>> >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
