On 28 February 2011 13:08, zoe slattery <[email protected]> wrote: > On 28/02/2011 12:44, Guillaume Nodet wrote: >> >> On Mon, Feb 28, 2011 at 13:37, zoe slattery<[email protected]> >> wrote: >>> >>> On 28/02/2011 12:21, Guillaume Nodet wrote: >>>> >>>> On Mon, Feb 28, 2011 at 12:36, zoe slattery<[email protected]> >>>> wrote: >>>>> >>>>> Hi - After 4 or 5 days spent fighting the maven release plugin I have >>>>> something that is probably worth discussing. >>>>> >>>>> For releasing modules I think I'm down to two options. >>>>> >>>>> 1) We follow Guillaume's suggestion of having release artifact versions >>>>> different to bundle versions >>>>> - We can release by module as we do now >>>>> - Might have unexpected side effects where people expect the >>>>> BundleVersion to be the same as the version in the artifact name. >>>>> - We release the same code more than once, with different >>>>> artifact >>>>> names >>>>> >>>>> 2) We release each bundle in a module, only where the bundle has >>>>> actually >>>>> changed. Then find a way to distribute bundles that we know work >>>>> together. >>>>> - A bit more work to release, but not a stupid amount >>>>> - Versions in artifact names are the same as Bundle-Version >>>>> - We don't release the same code over again >>>>> >>>>> I have a sample of what a module distro might look like here : >>>>> >>>>> http://people.apache.org/~zoe/TEST-org.apche.aries.proxy-distro-0.8.zip. >>>>> It >>>>> contains the build-able source for the whole proxy module, and, under >>>>> 'bundles', the proxy jars corresponding to the release. >>>> >>>> That link doesn't seem to work for me. >>> >>> Sorry - spelling wrong. >>> >>> http://people.apache.org/~zoe/TEST-org.apache.aries.proxy-distro-0.8.zip >>> >>> >>>>> I'd like some feedback on a couple of things: >>>>> >>>>> (a) Do people feel it's necessary to have the buildable module source >>>>> in >>>>> a >>>>> distro? I ask this because this is the part that's been very had to do. >>>>> Just >>>>> collecting up the bundles is very easy. >>>> >>>> The source assembly has usually worked fine for me. AFAIK, a >>>> buildable source distribution is a requirement for an ASF release, but >>>> the build phase does not have to be a single command, as long as you >>>> can build the same artifacts somehow , it's fine. >>> >>> Yes - and it works great if we stick with the existing multi-module >>> release. >>> But if we switch to release by bundle you will get the source for each >>> bundle fine, if you want the source for the _whole module_ in a distro >>> it's >>> very hard. If the distro can just be a collection of released bundles >>> (jars) >>> that we know work together - that is easily done. Does that make sense? >>>>> >>>>> (b) Does option 2 seem like a reasonable way forward? I think we could >>>>> construct something similar for a complete aries distro with working >>>>> samples, but I haven't tried yet. >>>> >>>> I think we'd need some consensus as to when we need to release the >>>> uber-bundles, distros, examples and all. It's really not clear to me >>>> as to when I would release a single bundle vs examples and all. >>>> Because if we don't release them, there's little point in maintaining >>>> them at all. >>> >>> Yes - agreed. All I was looking at at this stage is solving the issue in >>> a >>> single module release. So the process for proxy*, in the case where the >>> proxy-api has already been released would be >>> 1) Release proxy-impl (depends on -api) >>> 2) Release proxy-bundle (depends on -impl and -api) >>> 3) Release itests >>> 4) Release proxy -distro. >>> >>> The distro provides two things, (a) a set of bundles for a release which >>> we >>> know run together, (b) the source for the entire proxy module, including >>> in >>> this case, the source for -api >>> >>> I think it would be possible to create a similar sort of thing for >>> aries-distro, this would include samples and a set of bundles that the >>> samples work with. I haven't tried this yet - I hope it's not as hard as >>> creating the module distro was, but I expect it will be. >> >> Maybe I'm silly, but if we add the proxy-api, don't we have a >> release-per-module policy and not a release-per-bundle anymore ? >> The release could then be automated using a shell / ant script ... > > I'm sure you're not silly - I probably haven't explained it well enough. The > distro is just a convenience, in fact all it contains is stuff that has > effectively already been released (that being the case - does it even need > to be released?) It's just way of ensuring that, if you were just to release > a single bundle (say the -bundle) the other aries artifacts that it depends > on are packaged up in a distribution and someone wanting all of the proxy > bundles at a consistent level could just extract the distribution. Maybe it > just is unnecessary?
I think that's something we should release. It's an alternative to an uber bundle: an uber bundle says here's a bunch of bundles all in one bundle which we have tested to work together (with a bit of extra code to ensure all the activators are driven). One bundle is deployed, if it needs to be updated the provisioning runtime has to reprovision the whole thing. The distro approach says the same about the bundles working together, now because what's being deployed is multiple bundles, the provisioning runtime can update just a smaller part if necessary. By releasing the distro we set in stone the set of bundles w/versions that work together. If it's just a list on our website, then it's IMO less consumable and fragile (for example no vote on that set of bundles w/versions). > > > Z >>> >>>>> Zoė >>>>> >>>>> >>>>> >>>>> >>>>> <http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip> >>>>> >>>>> >>>> >>> >> >> > >
