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 ... > > >>> Zoė >>> >>> >>> >>> <http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip> >>> >>> >> >> > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
