You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by zoe slattery <zo...@gmail.com> on 2011/02/28 12:36:22 UTC
Release by module - proposal?
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.
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.
(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.
Zoë
<http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip>
Re: Release by module - proposal?
Posted by zoe slattery <zo...@gmail.com>.
On 01/03/2011 12:43, Alasdair Nottingham wrote:
> On 1 March 2011 11:36, Guillaume Nodet<gn...@gmail.com> wrote:
>> I'm really lost. I thought you absolutely wanted a per-bundle release
>> cycle and now you're advocating a single release with everything
>> inside. Could you please clarify ?
>>
> I'm not advocating a single release. I'm advocating having less
> distributions than Zoe's
> proposal requires. Zoe's proposal says we have a distribution per
> current module and I am
> suggesting we want less than that. A distribution that will give you
> everything you need for
> blueprint, a distribution with everything you need for applications etc.
I think I agree. So, I suggest that we'd do release by bundles, but have
the following 'distributions'
- blueprint (includes all of the aries-* jars that blueprint needs)
- application-runtime (includes all of the aries-* jars required for a
non-isolating runtime)
- application-runtime-isolated (includes all of the aries-* jars
required for a isolating runtime)
- samples (a distribution of the samples, including source, in which the
samples assembly projects include a specific set of aries bundles)
This makes more sense to me than including source in a distribution. And
I _think_ it meets the most likely users' requirement of knowing what
bundles the need.
Zoe
>> On Tue, Mar 1, 2011 at 12:10, Alasdair Nottingham<no...@apache.org> wrote:
>>> Hi,
>>>
>>> I like option 2. I would also suggest we have a courser grained
>>> distribution model. I do not see a need to release proxy and quiesce
>>> distributions. I think it would be useful to release blueprint,
>>> application and jndi distributions though that pulled in dependencies.
>>> So a blueprint distribution would contain blueprint + proxy + util,
>>> and jndi would be jndi + proxy + util, and so on. This would make it
>>> easier for people to get "something that works" than it is today, but
>>> it doesn't result in lots and lots of distributions. I do not think we
>>> need a distribution per module.
>>>
>>> Alasdair
>>>
>>> On 28 February 2011 11:36, zoe slattery<zo...@gmail.com> 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.
>>>>
>>>> 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.
>>>> (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.
>>>>
>>>> Zoė
>>>>
>>>>
>>>> <http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip>
>>>>
>>>>
>>>
>>>
>>> --
>>> Alasdair Nottingham
>>> not@apache.org
>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
Re: Release by module - proposal?
Posted by Alasdair Nottingham <no...@apache.org>.
On 1 March 2011 11:36, Guillaume Nodet <gn...@gmail.com> wrote:
> I'm really lost. I thought you absolutely wanted a per-bundle release
> cycle and now you're advocating a single release with everything
> inside. Could you please clarify ?
>
I'm not advocating a single release. I'm advocating having less
distributions than Zoe's
proposal requires. Zoe's proposal says we have a distribution per
current module and I am
suggesting we want less than that. A distribution that will give you
everything you need for
blueprint, a distribution with everything you need for applications etc.
> On Tue, Mar 1, 2011 at 12:10, Alasdair Nottingham <no...@apache.org> wrote:
>> Hi,
>>
>> I like option 2. I would also suggest we have a courser grained
>> distribution model. I do not see a need to release proxy and quiesce
>> distributions. I think it would be useful to release blueprint,
>> application and jndi distributions though that pulled in dependencies.
>> So a blueprint distribution would contain blueprint + proxy + util,
>> and jndi would be jndi + proxy + util, and so on. This would make it
>> easier for people to get "something that works" than it is today, but
>> it doesn't result in lots and lots of distributions. I do not think we
>> need a distribution per module.
>>
>> Alasdair
>>
>> On 28 February 2011 11:36, zoe slattery <zo...@gmail.com> 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.
>>>
>>> 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.
>>> (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.
>>>
>>> Zoė
>>>
>>>
>>> <http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip>
>>>
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: Release by module - proposal?
Posted by Guillaume Nodet <gn...@gmail.com>.
I'm really lost. I thought you absolutely wanted a per-bundle release
cycle and now you're advocating a single release with everything
inside. Could you please clarify ?
On Tue, Mar 1, 2011 at 12:10, Alasdair Nottingham <no...@apache.org> wrote:
> Hi,
>
> I like option 2. I would also suggest we have a courser grained
> distribution model. I do not see a need to release proxy and quiesce
> distributions. I think it would be useful to release blueprint,
> application and jndi distributions though that pulled in dependencies.
> So a blueprint distribution would contain blueprint + proxy + util,
> and jndi would be jndi + proxy + util, and so on. This would make it
> easier for people to get "something that works" than it is today, but
> it doesn't result in lots and lots of distributions. I do not think we
> need a distribution per module.
>
> Alasdair
>
> On 28 February 2011 11:36, zoe slattery <zo...@gmail.com> 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.
>>
>> 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.
>> (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.
>>
>> Zoė
>>
>>
>> <http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip>
>>
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Release by module - proposal?
Posted by Alasdair Nottingham <no...@apache.org>.
On 1 March 2011 11:27, zoe slattery <zo...@gmail.com> wrote:
> On 01/03/2011 11:10, Alasdair Nottingham wrote:
>>
>> Hi,
>>
>> I like option 2. I would also suggest we have a courser grained
>> distribution model. I do not see a need to release proxy and quiesce
>> distributions. I think it would be useful to release blueprint,
>> application and jndi distributions though that pulled in dependencies.
>> So a blueprint distribution would contain blueprint + proxy + util,
>> and jndi would be jndi + proxy + util, and so on. This would make it
>> easier for people to get "something that works" than it is today, but
>> it doesn't result in lots and lots of distributions. I do not think we
>> need a distribution per module.
>
> Right - when you say 'distribution' do you mean a collection of bundles that
> we know have been tested together? Or do you want source code in there as
> well?
I don't care about the source code. The source code is available via
the bundle releases. I really
see the distributions as an ease of use for getting our binaries.
> Would you have samples specific to each distribution?
I don't think so.
>
> Would you include anything other than org.apache.aries*
>
I don't know, I think it should be up for discussion.
> Z
>>
>> Alasdair
>>
>> On 28 February 2011 11:36, zoe slattery<zo...@gmail.com> 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.
>>>
>>> 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.
>>> (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.
>>>
>>> Zoė
>>>
>>>
>>>
>>> <http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip>
>>>
>>>
>>
>>
>
>
--
Alasdair Nottingham
not@apache.org
Re: Release by module - proposal?
Posted by zoe slattery <zo...@gmail.com>.
On 01/03/2011 11:10, Alasdair Nottingham wrote:
> Hi,
>
> I like option 2. I would also suggest we have a courser grained
> distribution model. I do not see a need to release proxy and quiesce
> distributions. I think it would be useful to release blueprint,
> application and jndi distributions though that pulled in dependencies.
> So a blueprint distribution would contain blueprint + proxy + util,
> and jndi would be jndi + proxy + util, and so on. This would make it
> easier for people to get "something that works" than it is today, but
> it doesn't result in lots and lots of distributions. I do not think we
> need a distribution per module.
Right - when you say 'distribution' do you mean a collection of bundles
that we know have been tested together? Or do you want source code in
there as well?
Would you have samples specific to each distribution?
Would you include anything other than org.apache.aries*
Z
> Alasdair
>
> On 28 February 2011 11:36, zoe slattery<zo...@gmail.com> 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.
>>
>> 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.
>> (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.
>>
>> Zoė
>>
>>
>> <http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip>
>>
>>
>
>
Re: Release by module - proposal?
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
I like option 2. I would also suggest we have a courser grained
distribution model. I do not see a need to release proxy and quiesce
distributions. I think it would be useful to release blueprint,
application and jndi distributions though that pulled in dependencies.
So a blueprint distribution would contain blueprint + proxy + util,
and jndi would be jndi + proxy + util, and so on. This would make it
easier for people to get "something that works" than it is today, but
it doesn't result in lots and lots of distributions. I do not think we
need a distribution per module.
Alasdair
On 28 February 2011 11:36, zoe slattery <zo...@gmail.com> 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.
>
> 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.
> (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.
>
> Zoė
>
>
> <http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip>
>
>
--
Alasdair Nottingham
not@apache.org
Re: Release by module - proposal?
Posted by Guillaume Nodet <gn...@gmail.com>.
At then end, users would have to use the same kind of commands we use
to build our own release, woulnd't they ?
If we have a per-bundle release, i'm fine with users having to build
them bundle by bundle too ...
On Mon, Feb 28, 2011 at 13:44, zoe slattery <zo...@gmail.com> wrote:
> PS...
>>>
>>> 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?
>
> If your last sentence means that you would be happy to build each module
> separately- then we don't need a module source zip. That would be much
> easier. I think anyone who wants to build and modify the whole module could
> quite easily grab the source from SVN, of if they were trying to build an
> old release, they'd just have to build the bundles separately - or write
> their own top level pom. I suppose building each one separately might be a
> bit of a pita for application :-/
>
> Z
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: Release by module - proposal?
Posted by zoe slattery <zo...@gmail.com>.
PS...
>> 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?
If your last sentence means that you would be happy to build each module
separately- then we don't need a module source zip. That would be much
easier. I think anyone who wants to build and modify the whole module
could quite easily grab the source from SVN, of if they were trying to
build an old release, they'd just have to build the bundles separately -
or write their own top level pom. I suppose building each one separately
might be a bit of a pita for application :-/
Z
Re: Release by module - proposal?
Posted by Jeremy Hughes <hu...@apache.org>.
On 28 February 2011 15:55, Guillaume Nodet <gn...@gmail.com> wrote:
> On Mon, Feb 28, 2011 at 15:40, Jeremy Hughes <hu...@apache.org> wrote:
...
>> 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).
>
> I fully agree with you on all points. What I don't understand is that
> if we have to release the distribution each time we release a bundle,
> we have a per-bundle versioning scheme, but a per-component release
> scheme, don't we ?
By 'component' do you mean module? e.g. proxy, blueprint, application
etc. If we do the above, then it sounds like the release scheme will
be to release a bundle along with a distro which contains that new
bundle and the most recent levels of all the other bundles in that
module - i.e. the set of bundles that work together. The distro
release will get its own version number which is not related to any
OSGi thing. The question is, what would the versioning scheme for the
distro be. I think we could use semantic versioning rules for that
too.
Jeremy
Re: Release by module - proposal?
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Feb 28, 2011 at 15:40, Jeremy Hughes <hu...@apache.org> wrote:
> On 28 February 2011 13:08, zoe slattery <zo...@gmail.com> wrote:
>> On 28/02/2011 12:44, Guillaume Nodet wrote:
>>>
>>> On Mon, Feb 28, 2011 at 13:37, zoe slattery<zo...@gmail.com>
>>> wrote:
>>>>
>>>> On 28/02/2011 12:21, Guillaume Nodet wrote:
>>>>>
>>>>> On Mon, Feb 28, 2011 at 12:36, zoe slattery<zo...@gmail.com>
>>>>> 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).
I fully agree with you on all points. What I don't understand is that
if we have to release the distribution each time we release a bundle,
we have a per-bundle versioning scheme, but a per-component release
scheme, don't we ?
>
>>
>>
>> Z
>>>>
>>>>>> 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
Re: Release by module - proposal?
Posted by Jeremy Hughes <hu...@apache.org>.
On 28 February 2011 13:08, zoe slattery <zo...@gmail.com> wrote:
> On 28/02/2011 12:44, Guillaume Nodet wrote:
>>
>> On Mon, Feb 28, 2011 at 13:37, zoe slattery<zo...@gmail.com>
>> wrote:
>>>
>>> On 28/02/2011 12:21, Guillaume Nodet wrote:
>>>>
>>>> On Mon, Feb 28, 2011 at 12:36, zoe slattery<zo...@gmail.com>
>>>> 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>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>
>
Re: Release by module - proposal?
Posted by zoe slattery <zo...@gmail.com>.
On 28/02/2011 12:44, Guillaume Nodet wrote:
> On Mon, Feb 28, 2011 at 13:37, zoe slattery<zo...@gmail.com> wrote:
>> On 28/02/2011 12:21, Guillaume Nodet wrote:
>>> On Mon, Feb 28, 2011 at 12:36, zoe slattery<zo...@gmail.com>
>>> 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?
Z
>>
>>>> Zoė
>>>>
>>>>
>>>>
>>>> <http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip>
>>>>
>>>>
>>>
>>
>
>
Re: Release by module - proposal?
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Feb 28, 2011 at 13:37, zoe slattery <zo...@gmail.com> wrote:
> On 28/02/2011 12:21, Guillaume Nodet wrote:
>>
>> On Mon, Feb 28, 2011 at 12:36, zoe slattery<zo...@gmail.com>
>> 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
Re: Release by module - proposal?
Posted by zoe slattery <zo...@gmail.com>.
On 28/02/2011 12:21, Guillaume Nodet wrote:
> On Mon, Feb 28, 2011 at 12:36, zoe slattery<zo...@gmail.com> 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.
>> Zoė
>>
>>
>> <http://people.apache.org/%7Ezoe/TEST-org.apache.aries.proxy-distro-0.8.zip>
>>
>>
>
>
Re: Release by module - proposal?
Posted by Guillaume Nodet <gn...@gmail.com>.
On Mon, Feb 28, 2011 at 12:36, zoe slattery <zo...@gmail.com> 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.
>
> 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.
> (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.
>
> 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