Mailing-List: contact dev-help@aries.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aries.apache.org
Received-SPF: pass (athena.apache.org: domain of gnodet@gmail.com designates
 74.125.82.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=rkQdTJk/LCDevdRyCeGXRYURq+OuJuOOsfe33dRmpQ3el32KLClwzrJzFkHKnOk6Bh
         ZguLIwZ2nIIN/6kYKfDyAvbab1ouJ+OvIndfxG5UyswiAOJuVBvhE1RpiSNiiurnSGwv
         MRFHX80BM2JsGLlllssSKMaLMYa6sE91Od3mE=
MIME-Version: 1.0
In-Reply-To: <4D6B9701.5070302@gmail.com>
References: <4D6B88B6.9080102@gmail.com>
	<AANLkTikDy8iQYsFVjTA3Z4sFzKaG8SKYOqsBwA3AnRcR@mail.gmail.com>
	<4D6B9701.5070302@gmail.com>
Date: Mon, 28 Feb 2011 13:44:42 +0100
Message-ID: <AANLkTik9FkS7YpAGWDORcdQfErrgj_2W_kUXtaSf=J2M@mail.gmail.com>
Subject: Re: Release by module - proposal?
From: Guillaume Nodet <gnodet@gmail.com>
To: dev@aries.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 28, 2011 at 13:37, zoe slattery <zoe.slattery@gmail.com> wrote:
> On 28/02/2011 12:21, Guillaume Nodet wrote:
>>
>> On Mon, Feb 28, 2011 at 12:36, zoe slattery<zoe.slattery@gmail.com>
>> =C2=A0wrote:
>>>
>>> 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
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0- We can release by module as we do now
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0- Might have unexpected side effects where p=
eople expect the
>>> BundleVersion to be the same as the version in the artifact name.
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0- We release the same code more than once, w=
ith different artifact
>>> names
>>>
>>> 2) We release each bundle in a module, only where the bundle has actual=
ly
>>> changed. Then find a way to distribute bundles that we know work
>>> together.
>>> =C2=A0 =C2=A0 =C2=A0 - A bit more work to release, but not a stupid amo=
unt
>>> =C2=A0 =C2=A0 =C2=A0 - Versions in artifact names are the same as Bundl=
e-Version
>>> =C2=A0 =C2=A0 =C2=A0 - 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 i=
n
>>> 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. =C2=A0AFAIK, 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 relea=
se.
> 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 (ja=
rs)
> that we know work together - that is =C2=A0easily done. Does that make se=
nse?
>>>
>>> (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. =C2=A0It'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=C4=97
>>>
>>>
>>>
>>> =C2=A0<http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-dist=
ro-0.8.zip>
>>>
>>>
>>
>>
>
>


--=20
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com