You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Jeremy Hughes <hu...@apache.org> on 2010/01/26 18:34:13 UTC
[DISCUSSION] Aries release
There's been a lot of activity lately so I'd like to propose we do a
release so we can get some wider user feedback. I think we should give
it a version of 0.1 and stick to versions <1 while we're in the
Incubator.
Then there is the question of whether to independently version the
high level modules or keep them lock-step. For now I think we should
keep them lock-step until we feel a need to change that.
What does everyone think?
Thanks,
Jeremy
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
Great thanks!
On 30 March 2010 14:50, Donald Woods <dw...@apache.org> wrote:
> OpenJPA 2.0.0-beta3 was released yesterday and is on repo1.
> It includes the Aries JPA requested fixes for:
> OPENJPA-1490 and OPENJPA-1524
>
>
> -Donald
>
>
> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>> There's been a lot of activity lately so I'd like to propose we do a
>> release so we can get some wider user feedback. I think we should give
>> it a version of 0.1 and stick to versions <1 while we're in the
>> Incubator.
>>
>> Then there is the question of whether to independently version the
>> high level modules or keep them lock-step. For now I think we should
>> keep them lock-step until we feel a need to change that.
>>
>> What does everyone think?
>>
>> Thanks,
>> Jeremy
>>
>
Re: [DISCUSSION] Aries release
Posted by Donald Woods <dw...@apache.org>.
OpenJPA 2.0.0-beta3 was released yesterday and is on repo1.
It includes the Aries JPA requested fixes for:
OPENJPA-1490 and OPENJPA-1524
-Donald
On 1/26/10 12:34 PM, Jeremy Hughes wrote:
> There's been a lot of activity lately so I'd like to propose we do a
> release so we can get some wider user feedback. I think we should give
> it a version of 0.1 and stick to versions <1 while we're in the
> Incubator.
>
> Then there is the question of whether to independently version the
> high level modules or keep them lock-step. For now I think we should
> keep them lock-step until we feel a need to change that.
>
> What does everyone think?
>
> Thanks,
> Jeremy
>
Re: [DISCUSSION] Aries release
Posted by Lin Sun <li...@gmail.com>.
I am in favor of doing a release too. version 0.1 is good.
For the modules we are releasing, if they are implementing a finalized
spec (for example blueprint), are we going to make any statement about
whether if it is spec compliant?
Lin
On Tue, Jan 26, 2010 at 12:34 PM, Jeremy Hughes <hu...@apache.org> wrote:
> There's been a lot of activity lately so I'd like to propose we do a
> release so we can get some wider user feedback. I think we should give
> it a version of 0.1 and stick to versions <1 while we're in the
> Incubator.
>
> Then there is the question of whether to independently version the
> high level modules or keep them lock-step. For now I think we should
> keep them lock-step until we feel a need to change that.
>
> What does everyone think?
>
> Thanks,
> Jeremy
>
Re: [DISCUSSION] Aries release
Posted by Donald Woods <dw...@apache.org>.
Goal is to close and publish the release Friday afternoon/night if no
problems are found, so the artifacts will be on the mirror repos Saturday.
-Donald
On 3/24/10 7:39 AM, Jeremy Hughes wrote:
> Hi Don, I think we're close. I had wanted to get artifacts up to vote
> on this week. I guess the open jpa release vote closes 2am GMT
> Saturday and those fixes for Aries JPA issues are OPENJPA-1491 and
> OPENJPA-1524 right? There are workaround for both the 1491 workaround
> is in Aries itself so that wouldn't affect users, the workaround for
> 1524 mentioned by Joe is a change to a blueprint.xml so impacts users.
>
> Ideally I'd like to pull in beta3. Anyone else have a preference?
>
> Cheers,
> Jeremy
>
> There I think it's worth waiting that little bit extra for it so the
> 1524 workaround isn't needed
>
> On 24 March 2010 02:39, Donald Woods <dw...@apache.org> wrote:
>> What's the status on a release? I've just put a openjpa-2.0.0-beta3 up
>> for a vote, which includes fixes for two Aries JPA issues....
>>
>>
>> -Donald
>>
>>
>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>>> There's been a lot of activity lately so I'd like to propose we do a
>>> release so we can get some wider user feedback. I think we should give
>>> it a version of 0.1 and stick to versions <1 while we're in the
>>> Incubator.
>>>
>>> Then there is the question of whether to independently version the
>>> high level modules or keep them lock-step. For now I think we should
>>> keep them lock-step until we feel a need to change that.
>>>
>>> What does everyone think?
>>>
>>> Thanks,
>>> Jeremy
>>>
>>
>
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 25 March 2010 14:21, Jeremy Hughes <hu...@apache.org> wrote:
> On 24 March 2010 19:19, Joe Bohn <jo...@gmail.com> wrote:
>> Jeremy Hughes wrote:
>>>
>>> Hi Don, I think we're close. I had wanted to get artifacts up to vote
>>> on this week. I guess the open jpa release vote closes 2am GMT
>>> Saturday and those fixes for Aries JPA issues are OPENJPA-1491 and
>>> OPENJPA-1524 right? There are workaround for both the 1491 workaround
>>> is in Aries itself so that wouldn't affect users, the workaround for
>>> 1524 mentioned by Joe is a change to a blueprint.xml so impacts users.
>>>
>>> Ideally I'd like to pull in beta3. Anyone else have a preference?
>>
>> I agree that we should pull in beta3 and drop the work-around.
>>
>> I'd also like to point out that we are still using a SNAPSHOT version of the
>> maven-bundle-plugin (2.1.0-SNAPSHOT) and, as Guillaume mentioned in a recent
>> post - there are still changes being made to this plugin. We would need an
>> official release of this plugin before we could make an Aries release.
>
> OK, so what's the rule here w.r.t using SNAPSHOTS when you release? Is
> it: users shouldn't be expected to use SNAPSHOTs of depedencies. Or is
> it: people who want to build the code themselves shouldn't be expected
> to have to download SNAPSHOTs. If the former then maven-bundle-plugin
> can be a SNAPSHOT right?
>
> mvn release:prepare asks this:
>
> There are still some remaining snapshot dependencies.: Do you want to
> resolve them now? (yes/no) no: : yes
> Dependency type to resolve,: specify the selection number ( 0:All
> 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3)
> 1: :
>
> is it ok release if you accept the default of 1?
well that's frustrating ... it seems even if I select 1, it complains
that the default-parent pom is using a SNAPSHOT of maven-bundle-plugin
even though it is a plugin dependency not a project dependency!
>
>> Is
>> this something that you are working on Guillaume?
>>
>>
>> Joe
>>
>>
>>>
>>> Cheers,
>>> Jeremy
>>>
>>> There I think it's worth waiting that little bit extra for it so the
>>> 1524 workaround isn't needed
>>>
>>> On 24 March 2010 02:39, Donald Woods <dw...@apache.org> wrote:
>>>>
>>>> What's the status on a release? I've just put a openjpa-2.0.0-beta3 up
>>>> for a vote, which includes fixes for two Aries JPA issues....
>>>>
>>>>
>>>> -Donald
>>>>
>>>>
>>>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>>>>>
>>>>> There's been a lot of activity lately so I'd like to propose we do a
>>>>> release so we can get some wider user feedback. I think we should give
>>>>> it a version of 0.1 and stick to versions <1 while we're in the
>>>>> Incubator.
>>>>>
>>>>> Then there is the question of whether to independently version the
>>>>> high level modules or keep them lock-step. For now I think we should
>>>>> keep them lock-step until we feel a need to change that.
>>>>>
>>>>> What does everyone think?
>>>>>
>>>>> Thanks,
>>>>> Jeremy
>>>>>
>>>
>>
>>
>> --
>> Joe
>>
>
Re: [DISCUSSION] Aries release
Posted by Guillaume Nodet <gn...@gmail.com>.
Yes, I'm waiting for the current vote (which contains some dependencies for
the maven bundle plugin)
to be over so that I can start the release. But I'm thinking we could
safely revert to the last release for
now if needed. The only changes visible to the user are supposed to be on
blueprint support, but one of
the two changes has been reverted in aries, and the other one seems to not
gather consensus (the use of
the extended syntax) ...
So one way would be to revert to the relased version, test that everything
works .... and release.
On Tue, Mar 30, 2010 at 22:35, Jeremy Hughes <hu...@apache.org> wrote:
> On 25 March 2010 15:34, Guillaume Nodet <gn...@gmail.com> wrote:
> > No, it's not. We should never release anything with a snapshot
> dependency.
> > That would make the build much more likely to not succeed in the future,
> as
> > snapshots are meant to be deleted from repositories from time to time.
> >
> > FWIW, I could try to release the new maven bundle plugin next week or so.
> >
>
> Hi Guillaume, are you still expecting to release the maven bundle
> plugin this week. Then I think there are no SNAPSHOT dependencies in
> the way of an Aries release.
>
> Thanks,
> Jeremy
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 25 March 2010 15:34, Guillaume Nodet <gn...@gmail.com> wrote:
> No, it's not. We should never release anything with a snapshot dependency.
> That would make the build much more likely to not succeed in the future, as
> snapshots are meant to be deleted from repositories from time to time.
>
> FWIW, I could try to release the new maven bundle plugin next week or so.
>
Hi Guillaume, are you still expecting to release the maven bundle
plugin this week. Then I think there are no SNAPSHOT dependencies in
the way of an Aries release.
Thanks,
Jeremy
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
I agree - and that is the reason why I pointed out the SNAPSHOT. Even
though it is not included in our binary artifacts, it would prohibit the
ability to generate a consistent binary from the released source - and,
as Guillaume points out, we are really voting on the source.
IMHO we must remove this SNAPSHOT dependency before we can create a
release candidate - either by reverting to a released version of the
maven-bundle-plugin or by getting 2.1.0 released first.
Joe
Guillaume Nodet wrote:
> No, it's not. We should never release anything with a snapshot dependency.
> That would make the build much more likely to not succeed in the future, as
> snapshots are meant to be deleted from repositories from time to time.
>
> FWIW, I could try to release the new maven bundle plugin next week or so.
>
> On Thu, Mar 25, 2010 at 15:21, Jeremy Hughes <hu...@apache.org> wrote:
>
>> On 24 March 2010 19:19, Joe Bohn <jo...@gmail.com> wrote:
>>> Jeremy Hughes wrote:
>>>> Hi Don, I think we're close. I had wanted to get artifacts up to vote
>>>> on this week. I guess the open jpa release vote closes 2am GMT
>>>> Saturday and those fixes for Aries JPA issues are OPENJPA-1491 and
>>>> OPENJPA-1524 right? There are workaround for both the 1491 workaround
>>>> is in Aries itself so that wouldn't affect users, the workaround for
>>>> 1524 mentioned by Joe is a change to a blueprint.xml so impacts users.
>>>>
>>>> Ideally I'd like to pull in beta3. Anyone else have a preference?
>>> I agree that we should pull in beta3 and drop the work-around.
>>>
>>> I'd also like to point out that we are still using a SNAPSHOT version of
>> the
>>> maven-bundle-plugin (2.1.0-SNAPSHOT) and, as Guillaume mentioned in a
>> recent
>>> post - there are still changes being made to this plugin. We would need
>> an
>>> official release of this plugin before we could make an Aries release.
>> OK, so what's the rule here w.r.t using SNAPSHOTS when you release? Is
>> it: users shouldn't be expected to use SNAPSHOTs of depedencies. Or is
>> it: people who want to build the code themselves shouldn't be expected
>> to have to download SNAPSHOTs. If the former then maven-bundle-plugin
>> can be a SNAPSHOT right?
>>
>> mvn release:prepare asks this:
>>
>> There are still some remaining snapshot dependencies.: Do you want to
>> resolve them now? (yes/no) no: : yes
>> Dependency type to resolve,: specify the selection number ( 0:All
>> 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3)
>> 1: :
>>
>> is it ok release if you accept the default of 1?
>>
>>> Is
>>> this something that you are working on Guillaume?
>>>
>>>
>>> Joe
>>>
>>>
>>>> Cheers,
>>>> Jeremy
>>>>
>>>> There I think it's worth waiting that little bit extra for it so the
>>>> 1524 workaround isn't needed
>>>>
>>>> On 24 March 2010 02:39, Donald Woods <dw...@apache.org> wrote:
>>>>> What's the status on a release? I've just put a openjpa-2.0.0-beta3 up
>>>>> for a vote, which includes fixes for two Aries JPA issues....
>>>>>
>>>>>
>>>>> -Donald
>>>>>
>>>>>
>>>>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>>>>>> There's been a lot of activity lately so I'd like to propose we do a
>>>>>> release so we can get some wider user feedback. I think we should give
>>>>>> it a version of 0.1 and stick to versions <1 while we're in the
>>>>>> Incubator.
>>>>>>
>>>>>> Then there is the question of whether to independently version the
>>>>>> high level modules or keep them lock-step. For now I think we should
>>>>>> keep them lock-step until we feel a need to change that.
>>>>>>
>>>>>> What does everyone think?
>>>>>>
>>>>>> Thanks,
>>>>>> Jeremy
>>>>>>
>>>
>>> --
>>> Joe
>>>
>
>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Mar 25, 2010 at 15:41, Jeremy Hughes <hu...@apache.org> wrote:
> On 25 March 2010 14:34, Guillaume Nodet <gn...@gmail.com> wrote:
> > No, it's not. We should never release anything with a snapshot
> dependency.
> > That would make the build much more likely to not succeed in the future,
> as
> > snapshots are meant to be deleted from repositories from time to time.
>
> Do you mean if you wanted to rebuild a released Aries sources.zip? If
> so then I can see that.
>
Well, keep in mind that at Apache, *the official release* is the source
distribution, not prebuilt binaries that are provided for ease of
consumption.
>
> >
> > FWIW, I could try to release the new maven bundle plugin next week or so.
>
> That would be great thanks!
>
> >
> > On Thu, Mar 25, 2010 at 15:21, Jeremy Hughes <hu...@apache.org> wrote:
> >
> >> On 24 March 2010 19:19, Joe Bohn <jo...@gmail.com> wrote:
> >> > Jeremy Hughes wrote:
> >> >>
> >> >> Hi Don, I think we're close. I had wanted to get artifacts up to vote
> >> >> on this week. I guess the open jpa release vote closes 2am GMT
> >> >> Saturday and those fixes for Aries JPA issues are OPENJPA-1491 and
> >> >> OPENJPA-1524 right? There are workaround for both the 1491 workaround
> >> >> is in Aries itself so that wouldn't affect users, the workaround for
> >> >> 1524 mentioned by Joe is a change to a blueprint.xml so impacts
> users.
> >> >>
> >> >> Ideally I'd like to pull in beta3. Anyone else have a preference?
> >> >
> >> > I agree that we should pull in beta3 and drop the work-around.
> >> >
> >> > I'd also like to point out that we are still using a SNAPSHOT version
> of
> >> the
> >> > maven-bundle-plugin (2.1.0-SNAPSHOT) and, as Guillaume mentioned in a
> >> recent
> >> > post - there are still changes being made to this plugin. We would
> need
> >> an
> >> > official release of this plugin before we could make an Aries release.
> >>
> >> OK, so what's the rule here w.r.t using SNAPSHOTS when you release? Is
> >> it: users shouldn't be expected to use SNAPSHOTs of depedencies. Or is
> >> it: people who want to build the code themselves shouldn't be expected
> >> to have to download SNAPSHOTs. If the former then maven-bundle-plugin
> >> can be a SNAPSHOT right?
> >>
> >> mvn release:prepare asks this:
> >>
> >> There are still some remaining snapshot dependencies.: Do you want to
> >> resolve them now? (yes/no) no: : yes
> >> Dependency type to resolve,: specify the selection number ( 0:All
> >> 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3)
> >> 1: :
> >>
> >> is it ok release if you accept the default of 1?
> >>
> >> > Is
> >> > this something that you are working on Guillaume?
> >> >
> >> >
> >> > Joe
> >> >
> >> >
> >> >>
> >> >> Cheers,
> >> >> Jeremy
> >> >>
> >> >> There I think it's worth waiting that little bit extra for it so the
> >> >> 1524 workaround isn't needed
> >> >>
> >> >> On 24 March 2010 02:39, Donald Woods <dw...@apache.org> wrote:
> >> >>>
> >> >>> What's the status on a release? I've just put a openjpa-2.0.0-beta3
> up
> >> >>> for a vote, which includes fixes for two Aries JPA issues....
> >> >>>
> >> >>>
> >> >>> -Donald
> >> >>>
> >> >>>
> >> >>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
> >> >>>>
> >> >>>> There's been a lot of activity lately so I'd like to propose we do
> a
> >> >>>> release so we can get some wider user feedback. I think we should
> give
> >> >>>> it a version of 0.1 and stick to versions <1 while we're in the
> >> >>>> Incubator.
> >> >>>>
> >> >>>> Then there is the question of whether to independently version the
> >> >>>> high level modules or keep them lock-step. For now I think we
> should
> >> >>>> keep them lock-step until we feel a need to change that.
> >> >>>>
> >> >>>> What does everyone think?
> >> >>>>
> >> >>>> Thanks,
> >> >>>> Jeremy
> >> >>>>
> >> >>
> >> >
> >> >
> >> > --
> >> > Joe
> >> >
> >>
> >
> >
> >
> > --
> > Cheers,
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 25 March 2010 14:34, Guillaume Nodet <gn...@gmail.com> wrote:
> No, it's not. We should never release anything with a snapshot dependency.
> That would make the build much more likely to not succeed in the future, as
> snapshots are meant to be deleted from repositories from time to time.
Do you mean if you wanted to rebuild a released Aries sources.zip? If
so then I can see that.
>
> FWIW, I could try to release the new maven bundle plugin next week or so.
That would be great thanks!
>
> On Thu, Mar 25, 2010 at 15:21, Jeremy Hughes <hu...@apache.org> wrote:
>
>> On 24 March 2010 19:19, Joe Bohn <jo...@gmail.com> wrote:
>> > Jeremy Hughes wrote:
>> >>
>> >> Hi Don, I think we're close. I had wanted to get artifacts up to vote
>> >> on this week. I guess the open jpa release vote closes 2am GMT
>> >> Saturday and those fixes for Aries JPA issues are OPENJPA-1491 and
>> >> OPENJPA-1524 right? There are workaround for both the 1491 workaround
>> >> is in Aries itself so that wouldn't affect users, the workaround for
>> >> 1524 mentioned by Joe is a change to a blueprint.xml so impacts users.
>> >>
>> >> Ideally I'd like to pull in beta3. Anyone else have a preference?
>> >
>> > I agree that we should pull in beta3 and drop the work-around.
>> >
>> > I'd also like to point out that we are still using a SNAPSHOT version of
>> the
>> > maven-bundle-plugin (2.1.0-SNAPSHOT) and, as Guillaume mentioned in a
>> recent
>> > post - there are still changes being made to this plugin. We would need
>> an
>> > official release of this plugin before we could make an Aries release.
>>
>> OK, so what's the rule here w.r.t using SNAPSHOTS when you release? Is
>> it: users shouldn't be expected to use SNAPSHOTs of depedencies. Or is
>> it: people who want to build the code themselves shouldn't be expected
>> to have to download SNAPSHOTs. If the former then maven-bundle-plugin
>> can be a SNAPSHOT right?
>>
>> mvn release:prepare asks this:
>>
>> There are still some remaining snapshot dependencies.: Do you want to
>> resolve them now? (yes/no) no: : yes
>> Dependency type to resolve,: specify the selection number ( 0:All
>> 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3)
>> 1: :
>>
>> is it ok release if you accept the default of 1?
>>
>> > Is
>> > this something that you are working on Guillaume?
>> >
>> >
>> > Joe
>> >
>> >
>> >>
>> >> Cheers,
>> >> Jeremy
>> >>
>> >> There I think it's worth waiting that little bit extra for it so the
>> >> 1524 workaround isn't needed
>> >>
>> >> On 24 March 2010 02:39, Donald Woods <dw...@apache.org> wrote:
>> >>>
>> >>> What's the status on a release? I've just put a openjpa-2.0.0-beta3 up
>> >>> for a vote, which includes fixes for two Aries JPA issues....
>> >>>
>> >>>
>> >>> -Donald
>> >>>
>> >>>
>> >>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>> >>>>
>> >>>> There's been a lot of activity lately so I'd like to propose we do a
>> >>>> release so we can get some wider user feedback. I think we should give
>> >>>> it a version of 0.1 and stick to versions <1 while we're in the
>> >>>> Incubator.
>> >>>>
>> >>>> Then there is the question of whether to independently version the
>> >>>> high level modules or keep them lock-step. For now I think we should
>> >>>> keep them lock-step until we feel a need to change that.
>> >>>>
>> >>>> What does everyone think?
>> >>>>
>> >>>> Thanks,
>> >>>> Jeremy
>> >>>>
>> >>
>> >
>> >
>> > --
>> > Joe
>> >
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSSION] Aries release
Posted by Guillaume Nodet <gn...@gmail.com>.
No, it's not. We should never release anything with a snapshot dependency.
That would make the build much more likely to not succeed in the future, as
snapshots are meant to be deleted from repositories from time to time.
FWIW, I could try to release the new maven bundle plugin next week or so.
On Thu, Mar 25, 2010 at 15:21, Jeremy Hughes <hu...@apache.org> wrote:
> On 24 March 2010 19:19, Joe Bohn <jo...@gmail.com> wrote:
> > Jeremy Hughes wrote:
> >>
> >> Hi Don, I think we're close. I had wanted to get artifacts up to vote
> >> on this week. I guess the open jpa release vote closes 2am GMT
> >> Saturday and those fixes for Aries JPA issues are OPENJPA-1491 and
> >> OPENJPA-1524 right? There are workaround for both the 1491 workaround
> >> is in Aries itself so that wouldn't affect users, the workaround for
> >> 1524 mentioned by Joe is a change to a blueprint.xml so impacts users.
> >>
> >> Ideally I'd like to pull in beta3. Anyone else have a preference?
> >
> > I agree that we should pull in beta3 and drop the work-around.
> >
> > I'd also like to point out that we are still using a SNAPSHOT version of
> the
> > maven-bundle-plugin (2.1.0-SNAPSHOT) and, as Guillaume mentioned in a
> recent
> > post - there are still changes being made to this plugin. We would need
> an
> > official release of this plugin before we could make an Aries release.
>
> OK, so what's the rule here w.r.t using SNAPSHOTS when you release? Is
> it: users shouldn't be expected to use SNAPSHOTs of depedencies. Or is
> it: people who want to build the code themselves shouldn't be expected
> to have to download SNAPSHOTs. If the former then maven-bundle-plugin
> can be a SNAPSHOT right?
>
> mvn release:prepare asks this:
>
> There are still some remaining snapshot dependencies.: Do you want to
> resolve them now? (yes/no) no: : yes
> Dependency type to resolve,: specify the selection number ( 0:All
> 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3)
> 1: :
>
> is it ok release if you accept the default of 1?
>
> > Is
> > this something that you are working on Guillaume?
> >
> >
> > Joe
> >
> >
> >>
> >> Cheers,
> >> Jeremy
> >>
> >> There I think it's worth waiting that little bit extra for it so the
> >> 1524 workaround isn't needed
> >>
> >> On 24 March 2010 02:39, Donald Woods <dw...@apache.org> wrote:
> >>>
> >>> What's the status on a release? I've just put a openjpa-2.0.0-beta3 up
> >>> for a vote, which includes fixes for two Aries JPA issues....
> >>>
> >>>
> >>> -Donald
> >>>
> >>>
> >>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
> >>>>
> >>>> There's been a lot of activity lately so I'd like to propose we do a
> >>>> release so we can get some wider user feedback. I think we should give
> >>>> it a version of 0.1 and stick to versions <1 while we're in the
> >>>> Incubator.
> >>>>
> >>>> Then there is the question of whether to independently version the
> >>>> high level modules or keep them lock-step. For now I think we should
> >>>> keep them lock-step until we feel a need to change that.
> >>>>
> >>>> What does everyone think?
> >>>>
> >>>> Thanks,
> >>>> Jeremy
> >>>>
> >>
> >
> >
> > --
> > Joe
> >
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 24 March 2010 19:19, Joe Bohn <jo...@gmail.com> wrote:
> Jeremy Hughes wrote:
>>
>> Hi Don, I think we're close. I had wanted to get artifacts up to vote
>> on this week. I guess the open jpa release vote closes 2am GMT
>> Saturday and those fixes for Aries JPA issues are OPENJPA-1491 and
>> OPENJPA-1524 right? There are workaround for both the 1491 workaround
>> is in Aries itself so that wouldn't affect users, the workaround for
>> 1524 mentioned by Joe is a change to a blueprint.xml so impacts users.
>>
>> Ideally I'd like to pull in beta3. Anyone else have a preference?
>
> I agree that we should pull in beta3 and drop the work-around.
>
> I'd also like to point out that we are still using a SNAPSHOT version of the
> maven-bundle-plugin (2.1.0-SNAPSHOT) and, as Guillaume mentioned in a recent
> post - there are still changes being made to this plugin. We would need an
> official release of this plugin before we could make an Aries release.
OK, so what's the rule here w.r.t using SNAPSHOTS when you release? Is
it: users shouldn't be expected to use SNAPSHOTs of depedencies. Or is
it: people who want to build the code themselves shouldn't be expected
to have to download SNAPSHOTs. If the former then maven-bundle-plugin
can be a SNAPSHOT right?
mvn release:prepare asks this:
There are still some remaining snapshot dependencies.: Do you want to
resolve them now? (yes/no) no: : yes
Dependency type to resolve,: specify the selection number ( 0:All
1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): (0/1/2/3)
1: :
is it ok release if you accept the default of 1?
> Is
> this something that you are working on Guillaume?
>
>
> Joe
>
>
>>
>> Cheers,
>> Jeremy
>>
>> There I think it's worth waiting that little bit extra for it so the
>> 1524 workaround isn't needed
>>
>> On 24 March 2010 02:39, Donald Woods <dw...@apache.org> wrote:
>>>
>>> What's the status on a release? I've just put a openjpa-2.0.0-beta3 up
>>> for a vote, which includes fixes for two Aries JPA issues....
>>>
>>>
>>> -Donald
>>>
>>>
>>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>>>>
>>>> There's been a lot of activity lately so I'd like to propose we do a
>>>> release so we can get some wider user feedback. I think we should give
>>>> it a version of 0.1 and stick to versions <1 while we're in the
>>>> Incubator.
>>>>
>>>> Then there is the question of whether to independently version the
>>>> high level modules or keep them lock-step. For now I think we should
>>>> keep them lock-step until we feel a need to change that.
>>>>
>>>> What does everyone think?
>>>>
>>>> Thanks,
>>>> Jeremy
>>>>
>>
>
>
> --
> Joe
>
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
Jeremy Hughes wrote:
> Hi Don, I think we're close. I had wanted to get artifacts up to vote
> on this week. I guess the open jpa release vote closes 2am GMT
> Saturday and those fixes for Aries JPA issues are OPENJPA-1491 and
> OPENJPA-1524 right? There are workaround for both the 1491 workaround
> is in Aries itself so that wouldn't affect users, the workaround for
> 1524 mentioned by Joe is a change to a blueprint.xml so impacts users.
>
> Ideally I'd like to pull in beta3. Anyone else have a preference?
I agree that we should pull in beta3 and drop the work-around.
I'd also like to point out that we are still using a SNAPSHOT version of
the maven-bundle-plugin (2.1.0-SNAPSHOT) and, as Guillaume mentioned in
a recent post - there are still changes being made to this plugin. We
would need an official release of this plugin before we could make an
Aries release. Is this something that you are working on Guillaume?
Joe
>
> Cheers,
> Jeremy
>
> There I think it's worth waiting that little bit extra for it so the
> 1524 workaround isn't needed
>
> On 24 March 2010 02:39, Donald Woods <dw...@apache.org> wrote:
>> What's the status on a release? I've just put a openjpa-2.0.0-beta3 up
>> for a vote, which includes fixes for two Aries JPA issues....
>>
>>
>> -Donald
>>
>>
>> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>>> There's been a lot of activity lately so I'd like to propose we do a
>>> release so we can get some wider user feedback. I think we should give
>>> it a version of 0.1 and stick to versions <1 while we're in the
>>> Incubator.
>>>
>>> Then there is the question of whether to independently version the
>>> high level modules or keep them lock-step. For now I think we should
>>> keep them lock-step until we feel a need to change that.
>>>
>>> What does everyone think?
>>>
>>> Thanks,
>>> Jeremy
>>>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
Hi Don, I think we're close. I had wanted to get artifacts up to vote
on this week. I guess the open jpa release vote closes 2am GMT
Saturday and those fixes for Aries JPA issues are OPENJPA-1491 and
OPENJPA-1524 right? There are workaround for both the 1491 workaround
is in Aries itself so that wouldn't affect users, the workaround for
1524 mentioned by Joe is a change to a blueprint.xml so impacts users.
Ideally I'd like to pull in beta3. Anyone else have a preference?
Cheers,
Jeremy
There I think it's worth waiting that little bit extra for it so the
1524 workaround isn't needed
On 24 March 2010 02:39, Donald Woods <dw...@apache.org> wrote:
> What's the status on a release? I've just put a openjpa-2.0.0-beta3 up
> for a vote, which includes fixes for two Aries JPA issues....
>
>
> -Donald
>
>
> On 1/26/10 12:34 PM, Jeremy Hughes wrote:
>> There's been a lot of activity lately so I'd like to propose we do a
>> release so we can get some wider user feedback. I think we should give
>> it a version of 0.1 and stick to versions <1 while we're in the
>> Incubator.
>>
>> Then there is the question of whether to independently version the
>> high level modules or keep them lock-step. For now I think we should
>> keep them lock-step until we feel a need to change that.
>>
>> What does everyone think?
>>
>> Thanks,
>> Jeremy
>>
>
Re: [DISCUSSION] Aries release
Posted by Donald Woods <dw...@apache.org>.
What's the status on a release? I've just put a openjpa-2.0.0-beta3 up
for a vote, which includes fixes for two Aries JPA issues....
-Donald
On 1/26/10 12:34 PM, Jeremy Hughes wrote:
> There's been a lot of activity lately so I'd like to propose we do a
> release so we can get some wider user feedback. I think we should give
> it a version of 0.1 and stick to versions <1 while we're in the
> Incubator.
>
> Then there is the question of whether to independently version the
> high level modules or keep them lock-step. For now I think we should
> keep them lock-step until we feel a need to change that.
>
> What does everyone think?
>
> Thanks,
> Jeremy
>
RE: [DISCUSSION] Aries release
Posted by Timothy Ward <ti...@apache.org>.
I think we should definitely be including the JPA runtime in the release. The AriesTrader sample uses the JPA runtime, and it would be odd to have a release that can't run our own sample.
I am slightly concerned about the JMX component, as I know there have been several structural discussions on the list recently. Obviously if those issues have been resolved to everyone's satisfaction then there won't be a problem there.
Regards,
Tim
> Date: Fri, 19 Feb 2010 09:11:08 +0100
> Subject: Re: [DISCUSSION] Aries release
> From: gnodet@gmail.com
> To: aries-dev@incubator.apache.org
>
> I'd like to see at least those included:
> * blueprint
> * jmx
> * jndi
> * transaction
>
> I don't think applications are really usable yet and I haven't really
> looked at JPA yet, so can't tell about it.
> The transaction component is functional and we've been using it mostly
> unchanged since a long time in ServiceMix.
> Do you have any particular concerns with it ? (I'm not talking about
> declarative transactions for blueprint, note).
>
> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
> > Thanks for the response (even while on vacation!) ... and for volunteering
> > to be the release manager. Your response helps me get a better picture of
> > the plans.
> >
> > I was really just interested in the general objectives and timing since it
> > hadn't been discussed yet. To get the release out in Feb means it will be
> > delivered next week. I'm afraid the hill might be a little too steep to
> > climb that quickly but I'm happy to be proven wrong.
> >
> > The more communication the better. It's important to get everybody thinking
> > and planning along the same lines (or understand quickly if there are any
> > differences of opinion). Knowing that you are thinking of creating a
> > release candidate next week means that we should be getting more restrictive
> > on new content to avoid any unpleasant surprises.
> >
> > I don't have any strong opinions on what should be in or out - but in
> > general it doesn't make sense to release things that aren't functional. At
> > the moment I'm not sure what those are - but I suspect not all of the
> > components are fully functional yet (for example transaction).
> >
> > Best Regards,
> > Joe
> >
> >
> > Jeremy Hughes wrote:
> >>
> >> Hi Joe, sorry I started setting myself up tuesday but am now out on
> >> vacation until monday.
> >>
> >> Personally, I think the 0.1 release should serve to get what we have
> >> right now in the respectable form the ASF requires. So 'must haves'
> >> are to get the build in the right shape to create the distribution
> >> files that are acceptable to the IPMC. I think each main area of the
> >> code deserves at least a README to describe what's possible. Since
> >> this is the first release there are likely a few unknowns - w.r.t
> >> timing I hope/expect to get the release out this in feb. If there are
> >> particular JIRAs or other issues you feel should be included please
> >> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
> >> issues for 0.1 appropriately and issues not for 0.1 to target a new
> >> 0.2 version. WDYT?
> >>
> >> Cheers,
> >> Jeremy
> >>
> >> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
> >>>
> >>> Jeremy,
> >>>
> >>> What are your current thoughts and goals regarding the release and
> >>> potential
> >>> target dates?
> >>>
> >>> I think it would be good if you could summarize your thoughts in an email
> >>> or
> >>> perhaps on a page in the wiki that we can keep updated as we make
> >>> progress.
> >>> Of particular interest would be the content that we would like to see in
> >>> the first release (clarifying what we consider "must have" from "nice to
> >>> have"), the current status of that content, target dates for the release,
> >>> and the process that we plan to use to generate the release.
> >>>
> >>> Thanks,
> >>> Joe
> >>>
> >>>
> >>>
> >>> Jeremy Hughes wrote:
> >>>>
> >>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
> >>>>>
> >>>>> Great, thanks a lot. Let us know if you need any help.
> >>>>> I guess if you take some notes, it would be interesting to put those
> >>>>> on the wiki.
> >>>>
> >>>> Certainly will. It's been a while since I did one and the process has
> >>>> changed quite a bit :-)
> >>>>
> >>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi Kevan, thanks. I volunteer to be release manager.
> >>>>>>
> >>>>>> Jeremy
> >>>>>>
> >>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Sounds like the consensus is for a release with all components at a
> >>>>>>> 0.1
> >>>>>>> version number. Best to start with a simple versioning scheme, IMO.
> >>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
> >>>>>>>
> >>>>>>> Showing the ability to generate an Apache release is an important
> >>>>>>> step
> >>>>>>> for the community. Would definitely like to see this happen...
> >>>>>>>
> >>>>>>> We'll need a release manager. Any volunteers?
> >>>>>>>
> >>>>>>> --kevan
> >>>>>>>
> >>>>>
> >>>>> --
> >>>>> Cheers,
> >>>>> Guillaume Nodet
> >>>>> ------------------------
> >>>>> Blog: http://gnodet.blogspot.com/
> >>>>> ------------------------
> >>>>> Open Source SOA
> >>>>> http://fusesource.com
> >>>>>
> >>>
> >>> --
> >>> Joe
> >>>
> >>
> >
> >
> > --
> > Joe
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
_________________________________________________________________
Send us your Hotmail stories and be featured in our newsletter
http://clk.atdmt.com/UKM/go/195013117/direct/01/
Re: [DISCUSSION] Aries release
Posted by Jarek Gawor <jg...@gmail.com>.
I also would like to see the "web" module (or specifically the url
converter) to be included in the release. I've been improving it for
last few weeks and I think it's in a pretty decent shape.
Jarek
On Fri, Feb 19, 2010 at 3:11 AM, Guillaume Nodet <gn...@gmail.com> wrote:
> I'd like to see at least those included:
> * blueprint
> * jmx
> * jndi
> * transaction
>
> I don't think applications are really usable yet and I haven't really
> looked at JPA yet, so can't tell about it.
> The transaction component is functional and we've been using it mostly
> unchanged since a long time in ServiceMix.
> Do you have any particular concerns with it ? (I'm not talking about
> declarative transactions for blueprint, note).
>
> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>> Thanks for the response (even while on vacation!) ... and for volunteering
>> to be the release manager. Your response helps me get a better picture of
>> the plans.
>>
>> I was really just interested in the general objectives and timing since it
>> hadn't been discussed yet. To get the release out in Feb means it will be
>> delivered next week. I'm afraid the hill might be a little too steep to
>> climb that quickly but I'm happy to be proven wrong.
>>
>> The more communication the better. It's important to get everybody thinking
>> and planning along the same lines (or understand quickly if there are any
>> differences of opinion). Knowing that you are thinking of creating a
>> release candidate next week means that we should be getting more restrictive
>> on new content to avoid any unpleasant surprises.
>>
>> I don't have any strong opinions on what should be in or out - but in
>> general it doesn't make sense to release things that aren't functional. At
>> the moment I'm not sure what those are - but I suspect not all of the
>> components are fully functional yet (for example transaction).
>>
>> Best Regards,
>> Joe
>>
>>
>> Jeremy Hughes wrote:
>>>
>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>> vacation until monday.
>>>
>>> Personally, I think the 0.1 release should serve to get what we have
>>> right now in the respectable form the ASF requires. So 'must haves'
>>> are to get the build in the right shape to create the distribution
>>> files that are acceptable to the IPMC. I think each main area of the
>>> code deserves at least a README to describe what's possible. Since
>>> this is the first release there are likely a few unknowns - w.r.t
>>> timing I hope/expect to get the release out this in feb. If there are
>>> particular JIRAs or other issues you feel should be included please
>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>> 0.2 version. WDYT?
>>>
>>> Cheers,
>>> Jeremy
>>>
>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>
>>>> Jeremy,
>>>>
>>>> What are your current thoughts and goals regarding the release and
>>>> potential
>>>> target dates?
>>>>
>>>> I think it would be good if you could summarize your thoughts in an email
>>>> or
>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>> progress.
>>>> Of particular interest would be the content that we would like to see in
>>>> the first release (clarifying what we consider "must have" from "nice to
>>>> have"), the current status of that content, target dates for the release,
>>>> and the process that we plan to use to generate the release.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>>
>>>>
>>>> Jeremy Hughes wrote:
>>>>>
>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>
>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>> on the wiki.
>>>>>
>>>>> Certainly will. It's been a while since I did one and the process has
>>>>> changed quite a bit :-)
>>>>>
>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>
>>>>>>> Jeremy
>>>>>>>
>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>> 0.1
>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>
>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>> step
>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>
>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>
>>>>>>>> --kevan
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>
>>>> --
>>>> Joe
>>>>
>>>
>>
>>
>> --
>> Joe
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSSION] Aries release
Posted by Guillaume Nodet <gn...@gmail.com>.
Well, the fact that Aries is incubating has nothing to do with the
quality / readiness of the code.
But if we're releasing with 0.1, i guess that's a sufficient warning ...
On Fri, Feb 19, 2010 at 18:33, Timothy Ward <ti...@apache.org> wrote:
>
>
>
>> Date: Fri, 19 Feb 2010 16:50:17 +0100
>> Subject: Re: [DISCUSSION] Aries release
>> From: gnodet@gmail.com
>> To: aries-dev@incubator.apache.org
>>
>> The fact that there's no persistence in the runtime is imho a show
>> stopper. If you restart the framework, you can't access the deployed
>> applications anymore. You can't install two applications containing
>> the same bundle (which means you can't install the same application
>> twice), etc ...
>>
>> I don't have any problems with realeasing it, but we should
>> explicitely mark this component with whatever tag will make our users
>> understand they can't really use it in production, just for testing /
>> preview.
>
> I'm not sure that that sort of warning is necessary for an incubating project's 0.1 release. I doubt anyone will expect what we have to be production ready until we have had some release candidates and a 1.0 driver.
>
>
>> Just my 2 cents.
>>
>> On Fri, Feb 19, 2010 at 12:54, Alasdair Nottingham <no...@apache.org> wrote:
>> > Hi,
>> >
>> > I want applications included in a release. I do not agree that they
>> > aren't usable. I think there are enhancements that can be made, but
>> > that doesn't mean they aren't usable as is.
>> >
>> > Alasdair
>> >
>> > On 19 February 2010 08:11, Guillaume Nodet <gn...@gmail.com> wrote:
>> >> I'd like to see at least those included:
>> >> * blueprint
>> >> * jmx
>> >> * jndi
>> >> * transaction
>> >>
>> >> I don't think applications are really usable yet and I haven't really
>> >> looked at JPA yet, so can't tell about it.
>> >> The transaction component is functional and we've been using it mostly
>> >> unchanged since a long time in ServiceMix.
>> >> Do you have any particular concerns with it ? (I'm not talking about
>> >> declarative transactions for blueprint, note).
>> >>
>> >> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>> >>> Thanks for the response (even while on vacation!) ... and for volunteering
>> >>> to be the release manager. Your response helps me get a better picture of
>> >>> the plans.
>> >>>
>> >>> I was really just interested in the general objectives and timing since it
>> >>> hadn't been discussed yet. To get the release out in Feb means it will be
>> >>> delivered next week. I'm afraid the hill might be a little too steep to
>> >>> climb that quickly but I'm happy to be proven wrong.
>> >>>
>> >>> The more communication the better. It's important to get everybody thinking
>> >>> and planning along the same lines (or understand quickly if there are any
>> >>> differences of opinion). Knowing that you are thinking of creating a
>> >>> release candidate next week means that we should be getting more restrictive
>> >>> on new content to avoid any unpleasant surprises.
>> >>>
>> >>> I don't have any strong opinions on what should be in or out - but in
>> >>> general it doesn't make sense to release things that aren't functional. At
>> >>> the moment I'm not sure what those are - but I suspect not all of the
>> >>> components are fully functional yet (for example transaction).
>> >>>
>> >>> Best Regards,
>> >>> Joe
>> >>>
>> >>>
>> >>> Jeremy Hughes wrote:
>> >>>>
>> >>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>> >>>> vacation until monday.
>> >>>>
>> >>>> Personally, I think the 0.1 release should serve to get what we have
>> >>>> right now in the respectable form the ASF requires. So 'must haves'
>> >>>> are to get the build in the right shape to create the distribution
>> >>>> files that are acceptable to the IPMC. I think each main area of the
>> >>>> code deserves at least a README to describe what's possible. Since
>> >>>> this is the first release there are likely a few unknowns - w.r.t
>> >>>> timing I hope/expect to get the release out this in feb. If there are
>> >>>> particular JIRAs or other issues you feel should be included please
>> >>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>> >>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>> >>>> 0.2 version. WDYT?
>> >>>>
>> >>>> Cheers,
>> >>>> Jeremy
>> >>>>
>> >>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>> >>>>>
>> >>>>> Jeremy,
>> >>>>>
>> >>>>> What are your current thoughts and goals regarding the release and
>> >>>>> potential
>> >>>>> target dates?
>> >>>>>
>> >>>>> I think it would be good if you could summarize your thoughts in an email
>> >>>>> or
>> >>>>> perhaps on a page in the wiki that we can keep updated as we make
>> >>>>> progress.
>> >>>>> Of particular interest would be the content that we would like to see in
>> >>>>> the first release (clarifying what we consider "must have" from "nice to
>> >>>>> have"), the current status of that content, target dates for the release,
>> >>>>> and the process that we plan to use to generate the release.
>> >>>>>
>> >>>>> Thanks,
>> >>>>> Joe
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> Jeremy Hughes wrote:
>> >>>>>>
>> >>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>> >>>>>>>
>> >>>>>>> Great, thanks a lot. Let us know if you need any help.
>> >>>>>>> I guess if you take some notes, it would be interesting to put those
>> >>>>>>> on the wiki.
>> >>>>>>
>> >>>>>> Certainly will. It's been a while since I did one and the process has
>> >>>>>> changed quite a bit :-)
>> >>>>>>
>> >>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>> >>>>>>> wrote:
>> >>>>>>>>
>> >>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>> >>>>>>>>
>> >>>>>>>> Jeremy
>> >>>>>>>>
>> >>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>> >>>>>>>> wrote:
>> >>>>>>>>>
>> >>>>>>>>> Sounds like the consensus is for a release with all components at a
>> >>>>>>>>> 0.1
>> >>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>> >>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>> >>>>>>>>>
>> >>>>>>>>> Showing the ability to generate an Apache release is an important
>> >>>>>>>>> step
>> >>>>>>>>> for the community. Would definitely like to see this happen...
>> >>>>>>>>>
>> >>>>>>>>> We'll need a release manager. Any volunteers?
>> >>>>>>>>>
>> >>>>>>>>> --kevan
>> >>>>>>>>>
>> >>>>>>>
>> >>>>>>> --
>> >>>>>>> Cheers,
>> >>>>>>> Guillaume Nodet
>> >>>>>>> ------------------------
>> >>>>>>> Blog: http://gnodet.blogspot.com/
>> >>>>>>> ------------------------
>> >>>>>>> Open Source SOA
>> >>>>>>> http://fusesource.com
>> >>>>>>>
>> >>>>>
>> >>>>> --
>> >>>>> Joe
>> >>>>>
>> >>>>
>> >>>
>> >>>
>> >>> --
>> >>> Joe
>> >>>
>> >>
>> >>
>> >>
>> >> --
>> >> Cheers,
>> >> Guillaume Nodet
>> >> ------------------------
>> >> Blog: http://gnodet.blogspot.com/
>> >> ------------------------
>> >> Open Source SOA
>> >> http://fusesource.com
>> >>
>> >
>> >
>> >
>> > --
>> > Alasdair Nottingham
>> > not@apache.org
>> >
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>
> _________________________________________________________________
> Send us your Hotmail stories and be featured in our newsletter
> http://clk.atdmt.com/UKM/go/195013117/direct/01/
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
RE: [DISCUSSION] Aries release
Posted by Timothy Ward <ti...@apache.org>.
> Date: Fri, 19 Feb 2010 16:50:17 +0100
> Subject: Re: [DISCUSSION] Aries release
> From: gnodet@gmail.com
> To: aries-dev@incubator.apache.org
>
> The fact that there's no persistence in the runtime is imho a show
> stopper. If you restart the framework, you can't access the deployed
> applications anymore. You can't install two applications containing
> the same bundle (which means you can't install the same application
> twice), etc ...
>
> I don't have any problems with realeasing it, but we should
> explicitely mark this component with whatever tag will make our users
> understand they can't really use it in production, just for testing /
> preview.
I'm not sure that that sort of warning is necessary for an incubating project's 0.1 release. I doubt anyone will expect what we have to be production ready until we have had some release candidates and a 1.0 driver.
> Just my 2 cents.
>
> On Fri, Feb 19, 2010 at 12:54, Alasdair Nottingham <no...@apache.org> wrote:
> > Hi,
> >
> > I want applications included in a release. I do not agree that they
> > aren't usable. I think there are enhancements that can be made, but
> > that doesn't mean they aren't usable as is.
> >
> > Alasdair
> >
> > On 19 February 2010 08:11, Guillaume Nodet <gn...@gmail.com> wrote:
> >> I'd like to see at least those included:
> >> * blueprint
> >> * jmx
> >> * jndi
> >> * transaction
> >>
> >> I don't think applications are really usable yet and I haven't really
> >> looked at JPA yet, so can't tell about it.
> >> The transaction component is functional and we've been using it mostly
> >> unchanged since a long time in ServiceMix.
> >> Do you have any particular concerns with it ? (I'm not talking about
> >> declarative transactions for blueprint, note).
> >>
> >> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
> >>> Thanks for the response (even while on vacation!) ... and for volunteering
> >>> to be the release manager. Your response helps me get a better picture of
> >>> the plans.
> >>>
> >>> I was really just interested in the general objectives and timing since it
> >>> hadn't been discussed yet. To get the release out in Feb means it will be
> >>> delivered next week. I'm afraid the hill might be a little too steep to
> >>> climb that quickly but I'm happy to be proven wrong.
> >>>
> >>> The more communication the better. It's important to get everybody thinking
> >>> and planning along the same lines (or understand quickly if there are any
> >>> differences of opinion). Knowing that you are thinking of creating a
> >>> release candidate next week means that we should be getting more restrictive
> >>> on new content to avoid any unpleasant surprises.
> >>>
> >>> I don't have any strong opinions on what should be in or out - but in
> >>> general it doesn't make sense to release things that aren't functional. At
> >>> the moment I'm not sure what those are - but I suspect not all of the
> >>> components are fully functional yet (for example transaction).
> >>>
> >>> Best Regards,
> >>> Joe
> >>>
> >>>
> >>> Jeremy Hughes wrote:
> >>>>
> >>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
> >>>> vacation until monday.
> >>>>
> >>>> Personally, I think the 0.1 release should serve to get what we have
> >>>> right now in the respectable form the ASF requires. So 'must haves'
> >>>> are to get the build in the right shape to create the distribution
> >>>> files that are acceptable to the IPMC. I think each main area of the
> >>>> code deserves at least a README to describe what's possible. Since
> >>>> this is the first release there are likely a few unknowns - w.r.t
> >>>> timing I hope/expect to get the release out this in feb. If there are
> >>>> particular JIRAs or other issues you feel should be included please
> >>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
> >>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
> >>>> 0.2 version. WDYT?
> >>>>
> >>>> Cheers,
> >>>> Jeremy
> >>>>
> >>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
> >>>>>
> >>>>> Jeremy,
> >>>>>
> >>>>> What are your current thoughts and goals regarding the release and
> >>>>> potential
> >>>>> target dates?
> >>>>>
> >>>>> I think it would be good if you could summarize your thoughts in an email
> >>>>> or
> >>>>> perhaps on a page in the wiki that we can keep updated as we make
> >>>>> progress.
> >>>>> Of particular interest would be the content that we would like to see in
> >>>>> the first release (clarifying what we consider "must have" from "nice to
> >>>>> have"), the current status of that content, target dates for the release,
> >>>>> and the process that we plan to use to generate the release.
> >>>>>
> >>>>> Thanks,
> >>>>> Joe
> >>>>>
> >>>>>
> >>>>>
> >>>>> Jeremy Hughes wrote:
> >>>>>>
> >>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
> >>>>>>>
> >>>>>>> Great, thanks a lot. Let us know if you need any help.
> >>>>>>> I guess if you take some notes, it would be interesting to put those
> >>>>>>> on the wiki.
> >>>>>>
> >>>>>> Certainly will. It's been a while since I did one and the process has
> >>>>>> changed quite a bit :-)
> >>>>>>
> >>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
> >>>>>>>>
> >>>>>>>> Jeremy
> >>>>>>>>
> >>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Sounds like the consensus is for a release with all components at a
> >>>>>>>>> 0.1
> >>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
> >>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
> >>>>>>>>>
> >>>>>>>>> Showing the ability to generate an Apache release is an important
> >>>>>>>>> step
> >>>>>>>>> for the community. Would definitely like to see this happen...
> >>>>>>>>>
> >>>>>>>>> We'll need a release manager. Any volunteers?
> >>>>>>>>>
> >>>>>>>>> --kevan
> >>>>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Cheers,
> >>>>>>> Guillaume Nodet
> >>>>>>> ------------------------
> >>>>>>> Blog: http://gnodet.blogspot.com/
> >>>>>>> ------------------------
> >>>>>>> Open Source SOA
> >>>>>>> http://fusesource.com
> >>>>>>>
> >>>>>
> >>>>> --
> >>>>> Joe
> >>>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> Joe
> >>>
> >>
> >>
> >>
> >> --
> >> Cheers,
> >> Guillaume Nodet
> >> ------------------------
> >> Blog: http://gnodet.blogspot.com/
> >> ------------------------
> >> Open Source SOA
> >> http://fusesource.com
> >>
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
> >
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
_________________________________________________________________
Send us your Hotmail stories and be featured in our newsletter
http://clk.atdmt.com/UKM/go/195013117/direct/01/
Re: [DISCUSSION] Aries release
Posted by Alasdair Nottingham <no...@apache.org>.
The ApplicationContextManager was originally intended more as a
sample, the thinking was that when you embed it into a runtime the
runtime might/would choose to provide an alternative implementation.
Not that this invalidates your point.
I think in order to support a 0.1 release I'll update it to make it
stateless, so when the service is removed it'll uninstall the bundles.
Not ideal in the long run, but at least next time the profile starts
you'll be able to install the application again.
I'll raise a JIRA for this.
Alasdair
On 19 February 2010 15:50, Guillaume Nodet <gn...@gmail.com> wrote:
> The fact that there's no persistence in the runtime is imho a show
> stopper. If you restart the framework, you can't access the deployed
> applications anymore. You can't install two applications containing
> the same bundle (which means you can't install the same application
> twice), etc ...
>
> I don't have any problems with realeasing it, but we should
> explicitely mark this component with whatever tag will make our users
> understand they can't really use it in production, just for testing /
> preview.
>
> Just my 2 cents.
>
> On Fri, Feb 19, 2010 at 12:54, Alasdair Nottingham <no...@apache.org> wrote:
>> Hi,
>>
>> I want applications included in a release. I do not agree that they
>> aren't usable. I think there are enhancements that can be made, but
>> that doesn't mean they aren't usable as is.
>>
>> Alasdair
>>
>> On 19 February 2010 08:11, Guillaume Nodet <gn...@gmail.com> wrote:
>>> I'd like to see at least those included:
>>> * blueprint
>>> * jmx
>>> * jndi
>>> * transaction
>>>
>>> I don't think applications are really usable yet and I haven't really
>>> looked at JPA yet, so can't tell about it.
>>> The transaction component is functional and we've been using it mostly
>>> unchanged since a long time in ServiceMix.
>>> Do you have any particular concerns with it ? (I'm not talking about
>>> declarative transactions for blueprint, note).
>>>
>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>> Thanks for the response (even while on vacation!) ... and for volunteering
>>>> to be the release manager. Your response helps me get a better picture of
>>>> the plans.
>>>>
>>>> I was really just interested in the general objectives and timing since it
>>>> hadn't been discussed yet. To get the release out in Feb means it will be
>>>> delivered next week. I'm afraid the hill might be a little too steep to
>>>> climb that quickly but I'm happy to be proven wrong.
>>>>
>>>> The more communication the better. It's important to get everybody thinking
>>>> and planning along the same lines (or understand quickly if there are any
>>>> differences of opinion). Knowing that you are thinking of creating a
>>>> release candidate next week means that we should be getting more restrictive
>>>> on new content to avoid any unpleasant surprises.
>>>>
>>>> I don't have any strong opinions on what should be in or out - but in
>>>> general it doesn't make sense to release things that aren't functional. At
>>>> the moment I'm not sure what those are - but I suspect not all of the
>>>> components are fully functional yet (for example transaction).
>>>>
>>>> Best Regards,
>>>> Joe
>>>>
>>>>
>>>> Jeremy Hughes wrote:
>>>>>
>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>> vacation until monday.
>>>>>
>>>>> Personally, I think the 0.1 release should serve to get what we have
>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>> are to get the build in the right shape to create the distribution
>>>>> files that are acceptable to the IPMC. I think each main area of the
>>>>> code deserves at least a README to describe what's possible. Since
>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>> timing I hope/expect to get the release out this in feb. If there are
>>>>> particular JIRAs or other issues you feel should be included please
>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>> 0.2 version. WDYT?
>>>>>
>>>>> Cheers,
>>>>> Jeremy
>>>>>
>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>
>>>>>> Jeremy,
>>>>>>
>>>>>> What are your current thoughts and goals regarding the release and
>>>>>> potential
>>>>>> target dates?
>>>>>>
>>>>>> I think it would be good if you could summarize your thoughts in an email
>>>>>> or
>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>> progress.
>>>>>> Of particular interest would be the content that we would like to see in
>>>>>> the first release (clarifying what we consider "must have" from "nice to
>>>>>> have"), the current status of that content, target dates for the release,
>>>>>> and the process that we plan to use to generate the release.
>>>>>>
>>>>>> Thanks,
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>>
>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>>> on the wiki.
>>>>>>>
>>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>>> changed quite a bit :-)
>>>>>>>
>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>
>>>>>>>>> Jeremy
>>>>>>>>>
>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>>> 0.1
>>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>
>>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>>> step
>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>
>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>
>>>>>>>>>> --kevan
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Joe
>>>>
>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>>
>>
>> --
>> 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: [DISCUSSION] Aries release
Posted by Guillaume Nodet <gn...@gmail.com>.
The fact that there's no persistence in the runtime is imho a show
stopper. If you restart the framework, you can't access the deployed
applications anymore. You can't install two applications containing
the same bundle (which means you can't install the same application
twice), etc ...
I don't have any problems with realeasing it, but we should
explicitely mark this component with whatever tag will make our users
understand they can't really use it in production, just for testing /
preview.
Just my 2 cents.
On Fri, Feb 19, 2010 at 12:54, Alasdair Nottingham <no...@apache.org> wrote:
> Hi,
>
> I want applications included in a release. I do not agree that they
> aren't usable. I think there are enhancements that can be made, but
> that doesn't mean they aren't usable as is.
>
> Alasdair
>
> On 19 February 2010 08:11, Guillaume Nodet <gn...@gmail.com> wrote:
>> I'd like to see at least those included:
>> * blueprint
>> * jmx
>> * jndi
>> * transaction
>>
>> I don't think applications are really usable yet and I haven't really
>> looked at JPA yet, so can't tell about it.
>> The transaction component is functional and we've been using it mostly
>> unchanged since a long time in ServiceMix.
>> Do you have any particular concerns with it ? (I'm not talking about
>> declarative transactions for blueprint, note).
>>
>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>> Thanks for the response (even while on vacation!) ... and for volunteering
>>> to be the release manager. Your response helps me get a better picture of
>>> the plans.
>>>
>>> I was really just interested in the general objectives and timing since it
>>> hadn't been discussed yet. To get the release out in Feb means it will be
>>> delivered next week. I'm afraid the hill might be a little too steep to
>>> climb that quickly but I'm happy to be proven wrong.
>>>
>>> The more communication the better. It's important to get everybody thinking
>>> and planning along the same lines (or understand quickly if there are any
>>> differences of opinion). Knowing that you are thinking of creating a
>>> release candidate next week means that we should be getting more restrictive
>>> on new content to avoid any unpleasant surprises.
>>>
>>> I don't have any strong opinions on what should be in or out - but in
>>> general it doesn't make sense to release things that aren't functional. At
>>> the moment I'm not sure what those are - but I suspect not all of the
>>> components are fully functional yet (for example transaction).
>>>
>>> Best Regards,
>>> Joe
>>>
>>>
>>> Jeremy Hughes wrote:
>>>>
>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>> vacation until monday.
>>>>
>>>> Personally, I think the 0.1 release should serve to get what we have
>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>> are to get the build in the right shape to create the distribution
>>>> files that are acceptable to the IPMC. I think each main area of the
>>>> code deserves at least a README to describe what's possible. Since
>>>> this is the first release there are likely a few unknowns - w.r.t
>>>> timing I hope/expect to get the release out this in feb. If there are
>>>> particular JIRAs or other issues you feel should be included please
>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>> 0.2 version. WDYT?
>>>>
>>>> Cheers,
>>>> Jeremy
>>>>
>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>
>>>>> Jeremy,
>>>>>
>>>>> What are your current thoughts and goals regarding the release and
>>>>> potential
>>>>> target dates?
>>>>>
>>>>> I think it would be good if you could summarize your thoughts in an email
>>>>> or
>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>> progress.
>>>>> Of particular interest would be the content that we would like to see in
>>>>> the first release (clarifying what we consider "must have" from "nice to
>>>>> have"), the current status of that content, target dates for the release,
>>>>> and the process that we plan to use to generate the release.
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>>
>>>>>
>>>>> Jeremy Hughes wrote:
>>>>>>
>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>
>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>> on the wiki.
>>>>>>
>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>> changed quite a bit :-)
>>>>>>
>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>
>>>>>>>> Jeremy
>>>>>>>>
>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>> 0.1
>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>
>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>> step
>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>
>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>
>>>>>>>>> --kevan
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>>
>>>
>>>
>>> --
>>> Joe
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Aries release
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
I want applications included in a release. I do not agree that they
aren't usable. I think there are enhancements that can be made, but
that doesn't mean they aren't usable as is.
Alasdair
On 19 February 2010 08:11, Guillaume Nodet <gn...@gmail.com> wrote:
> I'd like to see at least those included:
> * blueprint
> * jmx
> * jndi
> * transaction
>
> I don't think applications are really usable yet and I haven't really
> looked at JPA yet, so can't tell about it.
> The transaction component is functional and we've been using it mostly
> unchanged since a long time in ServiceMix.
> Do you have any particular concerns with it ? (I'm not talking about
> declarative transactions for blueprint, note).
>
> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>> Thanks for the response (even while on vacation!) ... and for volunteering
>> to be the release manager. Your response helps me get a better picture of
>> the plans.
>>
>> I was really just interested in the general objectives and timing since it
>> hadn't been discussed yet. To get the release out in Feb means it will be
>> delivered next week. I'm afraid the hill might be a little too steep to
>> climb that quickly but I'm happy to be proven wrong.
>>
>> The more communication the better. It's important to get everybody thinking
>> and planning along the same lines (or understand quickly if there are any
>> differences of opinion). Knowing that you are thinking of creating a
>> release candidate next week means that we should be getting more restrictive
>> on new content to avoid any unpleasant surprises.
>>
>> I don't have any strong opinions on what should be in or out - but in
>> general it doesn't make sense to release things that aren't functional. At
>> the moment I'm not sure what those are - but I suspect not all of the
>> components are fully functional yet (for example transaction).
>>
>> Best Regards,
>> Joe
>>
>>
>> Jeremy Hughes wrote:
>>>
>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>> vacation until monday.
>>>
>>> Personally, I think the 0.1 release should serve to get what we have
>>> right now in the respectable form the ASF requires. So 'must haves'
>>> are to get the build in the right shape to create the distribution
>>> files that are acceptable to the IPMC. I think each main area of the
>>> code deserves at least a README to describe what's possible. Since
>>> this is the first release there are likely a few unknowns - w.r.t
>>> timing I hope/expect to get the release out this in feb. If there are
>>> particular JIRAs or other issues you feel should be included please
>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>> 0.2 version. WDYT?
>>>
>>> Cheers,
>>> Jeremy
>>>
>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>
>>>> Jeremy,
>>>>
>>>> What are your current thoughts and goals regarding the release and
>>>> potential
>>>> target dates?
>>>>
>>>> I think it would be good if you could summarize your thoughts in an email
>>>> or
>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>> progress.
>>>> Of particular interest would be the content that we would like to see in
>>>> the first release (clarifying what we consider "must have" from "nice to
>>>> have"), the current status of that content, target dates for the release,
>>>> and the process that we plan to use to generate the release.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>>
>>>>
>>>> Jeremy Hughes wrote:
>>>>>
>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>
>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>> on the wiki.
>>>>>
>>>>> Certainly will. It's been a while since I did one and the process has
>>>>> changed quite a bit :-)
>>>>>
>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>
>>>>>>> Jeremy
>>>>>>>
>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>> 0.1
>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>
>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>> step
>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>
>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>
>>>>>>>> --kevan
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>
>>>> --
>>>> Joe
>>>>
>>>
>>
>>
>> --
>> Joe
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
Will you be including fixes for OPENJPA-1524 and OPENJPA-1491? It would
be helpful if these could be included.
Joe
Donald Woods wrote:
> I'll be starting a openjpa-2.0.0-beta2 release tomorrow, if that
> helps... :-)
>
>
> -Donald
>
>
> On 2/19/10 11:06 AM, Donald Woods wrote:
>> I'd like to see JPA included, as we've been working on some Aries
>> updates over in OpenJPA...
>>
>> Also, we're starting to discuss cutting a openjpa-2.0.0-beta2, which
>> would happen before the end of this month, if that helps to cut your
>> release..... The big changes from the original beta, would be we now
>> have a bundle activator and I'm looking at resolving a couple other
>> defects Tim opened, along with our builds/runtime now requiring Java SE 6.
>>
>> -Donald
>>
>>
>> On 2/19/10 3:11 AM, Guillaume Nodet wrote:
>>> I'd like to see at least those included:
>>> * blueprint
>>> * jmx
>>> * jndi
>>> * transaction
>>>
>>> I don't think applications are really usable yet and I haven't really
>>> looked at JPA yet, so can't tell about it.
>>> The transaction component is functional and we've been using it mostly
>>> unchanged since a long time in ServiceMix.
>>> Do you have any particular concerns with it ? (I'm not talking about
>>> declarative transactions for blueprint, note).
>>>
>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>> Thanks for the response (even while on vacation!) ... and for volunteering
>>>> to be the release manager. Your response helps me get a better picture of
>>>> the plans.
>>>>
>>>> I was really just interested in the general objectives and timing since it
>>>> hadn't been discussed yet. To get the release out in Feb means it will be
>>>> delivered next week. I'm afraid the hill might be a little too steep to
>>>> climb that quickly but I'm happy to be proven wrong.
>>>>
>>>> The more communication the better. It's important to get everybody thinking
>>>> and planning along the same lines (or understand quickly if there are any
>>>> differences of opinion). Knowing that you are thinking of creating a
>>>> release candidate next week means that we should be getting more restrictive
>>>> on new content to avoid any unpleasant surprises.
>>>>
>>>> I don't have any strong opinions on what should be in or out - but in
>>>> general it doesn't make sense to release things that aren't functional. At
>>>> the moment I'm not sure what those are - but I suspect not all of the
>>>> components are fully functional yet (for example transaction).
>>>>
>>>> Best Regards,
>>>> Joe
>>>>
>>>>
>>>> Jeremy Hughes wrote:
>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>> vacation until monday.
>>>>>
>>>>> Personally, I think the 0.1 release should serve to get what we have
>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>> are to get the build in the right shape to create the distribution
>>>>> files that are acceptable to the IPMC. I think each main area of the
>>>>> code deserves at least a README to describe what's possible. Since
>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>> timing I hope/expect to get the release out this in feb. If there are
>>>>> particular JIRAs or other issues you feel should be included please
>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>> 0.2 version. WDYT?
>>>>>
>>>>> Cheers,
>>>>> Jeremy
>>>>>
>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>> Jeremy,
>>>>>>
>>>>>> What are your current thoughts and goals regarding the release and
>>>>>> potential
>>>>>> target dates?
>>>>>>
>>>>>> I think it would be good if you could summarize your thoughts in an email
>>>>>> or
>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>> progress.
>>>>>> Of particular interest would be the content that we would like to see in
>>>>>> the first release (clarifying what we consider "must have" from "nice to
>>>>>> have"), the current status of that content, target dates for the release,
>>>>>> and the process that we plan to use to generate the release.
>>>>>>
>>>>>> Thanks,
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>>> on the wiki.
>>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>>> changed quite a bit :-)
>>>>>>>
>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>>> wrote:
>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>
>>>>>>>>> Jeremy
>>>>>>>>>
>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>>> 0.1
>>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>
>>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>>> step
>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>
>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>
>>>>>>>>>> --kevan
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>>
>>>> --
>>>> Joe
>>>>
>>>
>>>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Donald Woods <dw...@apache.org>.
The beta2 release contains the bundle activator code, but nothing for
OPENJPA-1490, OPENJPA-1491 or OPENJPA-1524.
-Donald
On 2/24/10 9:00 PM, Joe Bohn wrote:
> So that means you did not include solutions for the 2 JIRAs mentioned
> earlier?
>
> Joe
>
>
> Donald Woods wrote:
>> Just put a openjpa-2.0.0-beta2 up for a vote this afternoon, so
>> hopefully it'll be ready in time for your release to use it....
>>
>>
>> -Donald
>>
>>
>> On 2/23/10 4:38 PM, Donald Woods wrote:
>>> I'll be starting a openjpa-2.0.0-beta2 release tomorrow, if that
>>> helps... :-)
>>>
>>>
>>> -Donald
>>>
>>>
>>> On 2/19/10 11:06 AM, Donald Woods wrote:
>>>> I'd like to see JPA included, as we've been working on some Aries
>>>> updates over in OpenJPA...
>>>>
>>>> Also, we're starting to discuss cutting a openjpa-2.0.0-beta2, which
>>>> would happen before the end of this month, if that helps to cut your
>>>> release..... The big changes from the original beta, would be we now
>>>> have a bundle activator and I'm looking at resolving a couple other
>>>> defects Tim opened, along with our builds/runtime now requiring Java
>>>> SE 6.
>>>>
>>>> -Donald
>>>>
>>>>
>>>> On 2/19/10 3:11 AM, Guillaume Nodet wrote:
>>>>> I'd like to see at least those included:
>>>>> * blueprint
>>>>> * jmx
>>>>> * jndi
>>>>> * transaction
>>>>>
>>>>> I don't think applications are really usable yet and I haven't really
>>>>> looked at JPA yet, so can't tell about it.
>>>>> The transaction component is functional and we've been using it mostly
>>>>> unchanged since a long time in ServiceMix.
>>>>> Do you have any particular concerns with it ? (I'm not talking about
>>>>> declarative transactions for blueprint, note).
>>>>>
>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>> volunteering
>>>>>> to be the release manager. Your response helps me get a better
>>>>>> picture of
>>>>>> the plans.
>>>>>>
>>>>>> I was really just interested in the general objectives and timing
>>>>>> since it
>>>>>> hadn't been discussed yet. To get the release out in Feb means it
>>>>>> will be
>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>> steep to
>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>
>>>>>> The more communication the better. It's important to get
>>>>>> everybody thinking
>>>>>> and planning along the same lines (or understand quickly if there
>>>>>> are any
>>>>>> differences of opinion). Knowing that you are thinking of creating a
>>>>>> release candidate next week means that we should be getting more
>>>>>> restrictive
>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>
>>>>>> I don't have any strong opinions on what should be in or out - but in
>>>>>> general it doesn't make sense to release things that aren't
>>>>>> functional. At
>>>>>> the moment I'm not sure what those are - but I suspect not all of the
>>>>>> components are fully functional yet (for example transaction).
>>>>>>
>>>>>> Best Regards,
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>>>> vacation until monday.
>>>>>>>
>>>>>>> Personally, I think the 0.1 release should serve to get what we have
>>>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>>>> are to get the build in the right shape to create the distribution
>>>>>>> files that are acceptable to the IPMC. I think each main area of the
>>>>>>> code deserves at least a README to describe what's possible. Since
>>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>>> timing I hope/expect to get the release out this in feb. If there
>>>>>>> are
>>>>>>> particular JIRAs or other issues you feel should be included please
>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>>> target
>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>>>> 0.2 version. WDYT?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jeremy
>>>>>>>
>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>> Jeremy,
>>>>>>>>
>>>>>>>> What are your current thoughts and goals regarding the release and
>>>>>>>> potential
>>>>>>>> target dates?
>>>>>>>>
>>>>>>>> I think it would be good if you could summarize your thoughts in
>>>>>>>> an email
>>>>>>>> or
>>>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>>>> progress.
>>>>>>>> Of particular interest would be the content that we would like
>>>>>>>> to see in
>>>>>>>> the first release (clarifying what we consider "must have" from
>>>>>>>> "nice to
>>>>>>>> have"), the current status of that content, target dates for the
>>>>>>>> release,
>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>> I guess if you take some notes, it would be interesting to put
>>>>>>>>>> those
>>>>>>>>>> on the wiki.
>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>> process has
>>>>>>>>> changed quite a bit :-)
>>>>>>>>>
>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>
>>>>>>>>>>> Jeremy
>>>>>>>>>>>
>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>> components at a
>>>>>>>>>>>> 0.1
>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>> scheme, IMO.
>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>>>
>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>> important
>>>>>>>>>>>> step
>>>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>>>
>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>
>>>>>>>>>>>> --kevan
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Cheers,
>>>>>>>>>> Guillaume Nodet
>>>>>>>>>> ------------------------
>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>> ------------------------
>>>>>>>>>> Open Source SOA
>>>>>>>>>> http://fusesource.com
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>>>
>>>>>
>>
>
>
Re: [DISCUSSION] Aries release
Posted by Donald Woods <dw...@apache.org>.
The beta2 release contains the bundle activator code, but nothing for
OPENJPA-1490, OPENJPA-1491 or OPENJPA-1524.
-Donald
On 2/24/10 9:00 PM, Joe Bohn wrote:
> So that means you did not include solutions for the 2 JIRAs mentioned
> earlier?
>
> Joe
>
>
> Donald Woods wrote:
>> Just put a openjpa-2.0.0-beta2 up for a vote this afternoon, so
>> hopefully it'll be ready in time for your release to use it....
>>
>>
>> -Donald
>>
>>
>> On 2/23/10 4:38 PM, Donald Woods wrote:
>>> I'll be starting a openjpa-2.0.0-beta2 release tomorrow, if that
>>> helps... :-)
>>>
>>>
>>> -Donald
>>>
>>>
>>> On 2/19/10 11:06 AM, Donald Woods wrote:
>>>> I'd like to see JPA included, as we've been working on some Aries
>>>> updates over in OpenJPA...
>>>>
>>>> Also, we're starting to discuss cutting a openjpa-2.0.0-beta2, which
>>>> would happen before the end of this month, if that helps to cut your
>>>> release..... The big changes from the original beta, would be we now
>>>> have a bundle activator and I'm looking at resolving a couple other
>>>> defects Tim opened, along with our builds/runtime now requiring Java
>>>> SE 6.
>>>>
>>>> -Donald
>>>>
>>>>
>>>> On 2/19/10 3:11 AM, Guillaume Nodet wrote:
>>>>> I'd like to see at least those included:
>>>>> * blueprint
>>>>> * jmx
>>>>> * jndi
>>>>> * transaction
>>>>>
>>>>> I don't think applications are really usable yet and I haven't really
>>>>> looked at JPA yet, so can't tell about it.
>>>>> The transaction component is functional and we've been using it mostly
>>>>> unchanged since a long time in ServiceMix.
>>>>> Do you have any particular concerns with it ? (I'm not talking about
>>>>> declarative transactions for blueprint, note).
>>>>>
>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>> volunteering
>>>>>> to be the release manager. Your response helps me get a better
>>>>>> picture of
>>>>>> the plans.
>>>>>>
>>>>>> I was really just interested in the general objectives and timing
>>>>>> since it
>>>>>> hadn't been discussed yet. To get the release out in Feb means it
>>>>>> will be
>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>> steep to
>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>
>>>>>> The more communication the better. It's important to get
>>>>>> everybody thinking
>>>>>> and planning along the same lines (or understand quickly if there
>>>>>> are any
>>>>>> differences of opinion). Knowing that you are thinking of creating a
>>>>>> release candidate next week means that we should be getting more
>>>>>> restrictive
>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>
>>>>>> I don't have any strong opinions on what should be in or out - but in
>>>>>> general it doesn't make sense to release things that aren't
>>>>>> functional. At
>>>>>> the moment I'm not sure what those are - but I suspect not all of the
>>>>>> components are fully functional yet (for example transaction).
>>>>>>
>>>>>> Best Regards,
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>>>> vacation until monday.
>>>>>>>
>>>>>>> Personally, I think the 0.1 release should serve to get what we have
>>>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>>>> are to get the build in the right shape to create the distribution
>>>>>>> files that are acceptable to the IPMC. I think each main area of the
>>>>>>> code deserves at least a README to describe what's possible. Since
>>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>>> timing I hope/expect to get the release out this in feb. If there
>>>>>>> are
>>>>>>> particular JIRAs or other issues you feel should be included please
>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>>> target
>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>>>> 0.2 version. WDYT?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jeremy
>>>>>>>
>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>> Jeremy,
>>>>>>>>
>>>>>>>> What are your current thoughts and goals regarding the release and
>>>>>>>> potential
>>>>>>>> target dates?
>>>>>>>>
>>>>>>>> I think it would be good if you could summarize your thoughts in
>>>>>>>> an email
>>>>>>>> or
>>>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>>>> progress.
>>>>>>>> Of particular interest would be the content that we would like
>>>>>>>> to see in
>>>>>>>> the first release (clarifying what we consider "must have" from
>>>>>>>> "nice to
>>>>>>>> have"), the current status of that content, target dates for the
>>>>>>>> release,
>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>> I guess if you take some notes, it would be interesting to put
>>>>>>>>>> those
>>>>>>>>>> on the wiki.
>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>> process has
>>>>>>>>> changed quite a bit :-)
>>>>>>>>>
>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>
>>>>>>>>>>> Jeremy
>>>>>>>>>>>
>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>> components at a
>>>>>>>>>>>> 0.1
>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>> scheme, IMO.
>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>>>
>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>> important
>>>>>>>>>>>> step
>>>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>>>
>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>
>>>>>>>>>>>> --kevan
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Cheers,
>>>>>>>>>> Guillaume Nodet
>>>>>>>>>> ------------------------
>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>> ------------------------
>>>>>>>>>> Open Source SOA
>>>>>>>>>> http://fusesource.com
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>>>
>>>>>
>>
>
>
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
So that means you did not include solutions for the 2 JIRAs mentioned
earlier?
Joe
Donald Woods wrote:
> Just put a openjpa-2.0.0-beta2 up for a vote this afternoon, so
> hopefully it'll be ready in time for your release to use it....
>
>
> -Donald
>
>
> On 2/23/10 4:38 PM, Donald Woods wrote:
>> I'll be starting a openjpa-2.0.0-beta2 release tomorrow, if that
>> helps... :-)
>>
>>
>> -Donald
>>
>>
>> On 2/19/10 11:06 AM, Donald Woods wrote:
>>> I'd like to see JPA included, as we've been working on some Aries
>>> updates over in OpenJPA...
>>>
>>> Also, we're starting to discuss cutting a openjpa-2.0.0-beta2, which
>>> would happen before the end of this month, if that helps to cut your
>>> release..... The big changes from the original beta, would be we now
>>> have a bundle activator and I'm looking at resolving a couple other
>>> defects Tim opened, along with our builds/runtime now requiring Java SE 6.
>>>
>>> -Donald
>>>
>>>
>>> On 2/19/10 3:11 AM, Guillaume Nodet wrote:
>>>> I'd like to see at least those included:
>>>> * blueprint
>>>> * jmx
>>>> * jndi
>>>> * transaction
>>>>
>>>> I don't think applications are really usable yet and I haven't really
>>>> looked at JPA yet, so can't tell about it.
>>>> The transaction component is functional and we've been using it mostly
>>>> unchanged since a long time in ServiceMix.
>>>> Do you have any particular concerns with it ? (I'm not talking about
>>>> declarative transactions for blueprint, note).
>>>>
>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>> Thanks for the response (even while on vacation!) ... and for volunteering
>>>>> to be the release manager. Your response helps me get a better picture of
>>>>> the plans.
>>>>>
>>>>> I was really just interested in the general objectives and timing since it
>>>>> hadn't been discussed yet. To get the release out in Feb means it will be
>>>>> delivered next week. I'm afraid the hill might be a little too steep to
>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>
>>>>> The more communication the better. It's important to get everybody thinking
>>>>> and planning along the same lines (or understand quickly if there are any
>>>>> differences of opinion). Knowing that you are thinking of creating a
>>>>> release candidate next week means that we should be getting more restrictive
>>>>> on new content to avoid any unpleasant surprises.
>>>>>
>>>>> I don't have any strong opinions on what should be in or out - but in
>>>>> general it doesn't make sense to release things that aren't functional. At
>>>>> the moment I'm not sure what those are - but I suspect not all of the
>>>>> components are fully functional yet (for example transaction).
>>>>>
>>>>> Best Regards,
>>>>> Joe
>>>>>
>>>>>
>>>>> Jeremy Hughes wrote:
>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>>> vacation until monday.
>>>>>>
>>>>>> Personally, I think the 0.1 release should serve to get what we have
>>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>>> are to get the build in the right shape to create the distribution
>>>>>> files that are acceptable to the IPMC. I think each main area of the
>>>>>> code deserves at least a README to describe what's possible. Since
>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>> timing I hope/expect to get the release out this in feb. If there are
>>>>>> particular JIRAs or other issues you feel should be included please
>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>>> 0.2 version. WDYT?
>>>>>>
>>>>>> Cheers,
>>>>>> Jeremy
>>>>>>
>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>> Jeremy,
>>>>>>>
>>>>>>> What are your current thoughts and goals regarding the release and
>>>>>>> potential
>>>>>>> target dates?
>>>>>>>
>>>>>>> I think it would be good if you could summarize your thoughts in an email
>>>>>>> or
>>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>>> progress.
>>>>>>> Of particular interest would be the content that we would like to see in
>>>>>>> the first release (clarifying what we consider "must have" from "nice to
>>>>>>> have"), the current status of that content, target dates for the release,
>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jeremy Hughes wrote:
>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>>>> on the wiki.
>>>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>>>> changed quite a bit :-)
>>>>>>>>
>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>
>>>>>>>>>> Jeremy
>>>>>>>>>>
>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>>>> 0.1
>>>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>>
>>>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>>>> step
>>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>>
>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>
>>>>>>>>>>> --kevan
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> Open Source SOA
>>>>>>>>> http://fusesource.com
>>>>>>>>>
>>>>>>> --
>>>>>>> Joe
>>>>>>>
>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>>
>>>>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Donald Woods <dw...@apache.org>.
Just put a openjpa-2.0.0-beta2 up for a vote this afternoon, so
hopefully it'll be ready in time for your release to use it....
-Donald
On 2/23/10 4:38 PM, Donald Woods wrote:
> I'll be starting a openjpa-2.0.0-beta2 release tomorrow, if that
> helps... :-)
>
>
> -Donald
>
>
> On 2/19/10 11:06 AM, Donald Woods wrote:
>> I'd like to see JPA included, as we've been working on some Aries
>> updates over in OpenJPA...
>>
>> Also, we're starting to discuss cutting a openjpa-2.0.0-beta2, which
>> would happen before the end of this month, if that helps to cut your
>> release..... The big changes from the original beta, would be we now
>> have a bundle activator and I'm looking at resolving a couple other
>> defects Tim opened, along with our builds/runtime now requiring Java SE 6.
>>
>> -Donald
>>
>>
>> On 2/19/10 3:11 AM, Guillaume Nodet wrote:
>>> I'd like to see at least those included:
>>> * blueprint
>>> * jmx
>>> * jndi
>>> * transaction
>>>
>>> I don't think applications are really usable yet and I haven't really
>>> looked at JPA yet, so can't tell about it.
>>> The transaction component is functional and we've been using it mostly
>>> unchanged since a long time in ServiceMix.
>>> Do you have any particular concerns with it ? (I'm not talking about
>>> declarative transactions for blueprint, note).
>>>
>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>> Thanks for the response (even while on vacation!) ... and for volunteering
>>>> to be the release manager. Your response helps me get a better picture of
>>>> the plans.
>>>>
>>>> I was really just interested in the general objectives and timing since it
>>>> hadn't been discussed yet. To get the release out in Feb means it will be
>>>> delivered next week. I'm afraid the hill might be a little too steep to
>>>> climb that quickly but I'm happy to be proven wrong.
>>>>
>>>> The more communication the better. It's important to get everybody thinking
>>>> and planning along the same lines (or understand quickly if there are any
>>>> differences of opinion). Knowing that you are thinking of creating a
>>>> release candidate next week means that we should be getting more restrictive
>>>> on new content to avoid any unpleasant surprises.
>>>>
>>>> I don't have any strong opinions on what should be in or out - but in
>>>> general it doesn't make sense to release things that aren't functional. At
>>>> the moment I'm not sure what those are - but I suspect not all of the
>>>> components are fully functional yet (for example transaction).
>>>>
>>>> Best Regards,
>>>> Joe
>>>>
>>>>
>>>> Jeremy Hughes wrote:
>>>>>
>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>> vacation until monday.
>>>>>
>>>>> Personally, I think the 0.1 release should serve to get what we have
>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>> are to get the build in the right shape to create the distribution
>>>>> files that are acceptable to the IPMC. I think each main area of the
>>>>> code deserves at least a README to describe what's possible. Since
>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>> timing I hope/expect to get the release out this in feb. If there are
>>>>> particular JIRAs or other issues you feel should be included please
>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>> 0.2 version. WDYT?
>>>>>
>>>>> Cheers,
>>>>> Jeremy
>>>>>
>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>
>>>>>> Jeremy,
>>>>>>
>>>>>> What are your current thoughts and goals regarding the release and
>>>>>> potential
>>>>>> target dates?
>>>>>>
>>>>>> I think it would be good if you could summarize your thoughts in an email
>>>>>> or
>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>> progress.
>>>>>> Of particular interest would be the content that we would like to see in
>>>>>> the first release (clarifying what we consider "must have" from "nice to
>>>>>> have"), the current status of that content, target dates for the release,
>>>>>> and the process that we plan to use to generate the release.
>>>>>>
>>>>>> Thanks,
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>>
>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>>> on the wiki.
>>>>>>>
>>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>>> changed quite a bit :-)
>>>>>>>
>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>
>>>>>>>>> Jeremy
>>>>>>>>>
>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>>> 0.1
>>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>
>>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>>> step
>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>
>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>
>>>>>>>>>> --kevan
>>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Joe
>>>>
>>>
>>>
>>>
>>
>
Re: [DISCUSSION] Aries release
Posted by Donald Woods <dw...@apache.org>.
I'll be starting a openjpa-2.0.0-beta2 release tomorrow, if that
helps... :-)
-Donald
On 2/19/10 11:06 AM, Donald Woods wrote:
> I'd like to see JPA included, as we've been working on some Aries
> updates over in OpenJPA...
>
> Also, we're starting to discuss cutting a openjpa-2.0.0-beta2, which
> would happen before the end of this month, if that helps to cut your
> release..... The big changes from the original beta, would be we now
> have a bundle activator and I'm looking at resolving a couple other
> defects Tim opened, along with our builds/runtime now requiring Java SE 6.
>
> -Donald
>
>
> On 2/19/10 3:11 AM, Guillaume Nodet wrote:
>> I'd like to see at least those included:
>> * blueprint
>> * jmx
>> * jndi
>> * transaction
>>
>> I don't think applications are really usable yet and I haven't really
>> looked at JPA yet, so can't tell about it.
>> The transaction component is functional and we've been using it mostly
>> unchanged since a long time in ServiceMix.
>> Do you have any particular concerns with it ? (I'm not talking about
>> declarative transactions for blueprint, note).
>>
>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>> Thanks for the response (even while on vacation!) ... and for volunteering
>>> to be the release manager. Your response helps me get a better picture of
>>> the plans.
>>>
>>> I was really just interested in the general objectives and timing since it
>>> hadn't been discussed yet. To get the release out in Feb means it will be
>>> delivered next week. I'm afraid the hill might be a little too steep to
>>> climb that quickly but I'm happy to be proven wrong.
>>>
>>> The more communication the better. It's important to get everybody thinking
>>> and planning along the same lines (or understand quickly if there are any
>>> differences of opinion). Knowing that you are thinking of creating a
>>> release candidate next week means that we should be getting more restrictive
>>> on new content to avoid any unpleasant surprises.
>>>
>>> I don't have any strong opinions on what should be in or out - but in
>>> general it doesn't make sense to release things that aren't functional. At
>>> the moment I'm not sure what those are - but I suspect not all of the
>>> components are fully functional yet (for example transaction).
>>>
>>> Best Regards,
>>> Joe
>>>
>>>
>>> Jeremy Hughes wrote:
>>>>
>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>> vacation until monday.
>>>>
>>>> Personally, I think the 0.1 release should serve to get what we have
>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>> are to get the build in the right shape to create the distribution
>>>> files that are acceptable to the IPMC. I think each main area of the
>>>> code deserves at least a README to describe what's possible. Since
>>>> this is the first release there are likely a few unknowns - w.r.t
>>>> timing I hope/expect to get the release out this in feb. If there are
>>>> particular JIRAs or other issues you feel should be included please
>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>> 0.2 version. WDYT?
>>>>
>>>> Cheers,
>>>> Jeremy
>>>>
>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>
>>>>> Jeremy,
>>>>>
>>>>> What are your current thoughts and goals regarding the release and
>>>>> potential
>>>>> target dates?
>>>>>
>>>>> I think it would be good if you could summarize your thoughts in an email
>>>>> or
>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>> progress.
>>>>> Of particular interest would be the content that we would like to see in
>>>>> the first release (clarifying what we consider "must have" from "nice to
>>>>> have"), the current status of that content, target dates for the release,
>>>>> and the process that we plan to use to generate the release.
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>>
>>>>>
>>>>> Jeremy Hughes wrote:
>>>>>>
>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>
>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>> on the wiki.
>>>>>>
>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>> changed quite a bit :-)
>>>>>>
>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>
>>>>>>>> Jeremy
>>>>>>>>
>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>> 0.1
>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>
>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>> step
>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>
>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>
>>>>>>>>> --kevan
>>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>>
>>>
>>>
>>> --
>>> Joe
>>>
>>
>>
>>
>
Re: [DISCUSSION] Aries release
Posted by Donald Woods <dw...@apache.org>.
I'd like to see JPA included, as we've been working on some Aries
updates over in OpenJPA...
Also, we're starting to discuss cutting a openjpa-2.0.0-beta2, which
would happen before the end of this month, if that helps to cut your
release..... The big changes from the original beta, would be we now
have a bundle activator and I'm looking at resolving a couple other
defects Tim opened, along with our builds/runtime now requiring Java SE 6.
-Donald
On 2/19/10 3:11 AM, Guillaume Nodet wrote:
> I'd like to see at least those included:
> * blueprint
> * jmx
> * jndi
> * transaction
>
> I don't think applications are really usable yet and I haven't really
> looked at JPA yet, so can't tell about it.
> The transaction component is functional and we've been using it mostly
> unchanged since a long time in ServiceMix.
> Do you have any particular concerns with it ? (I'm not talking about
> declarative transactions for blueprint, note).
>
> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>> Thanks for the response (even while on vacation!) ... and for volunteering
>> to be the release manager. Your response helps me get a better picture of
>> the plans.
>>
>> I was really just interested in the general objectives and timing since it
>> hadn't been discussed yet. To get the release out in Feb means it will be
>> delivered next week. I'm afraid the hill might be a little too steep to
>> climb that quickly but I'm happy to be proven wrong.
>>
>> The more communication the better. It's important to get everybody thinking
>> and planning along the same lines (or understand quickly if there are any
>> differences of opinion). Knowing that you are thinking of creating a
>> release candidate next week means that we should be getting more restrictive
>> on new content to avoid any unpleasant surprises.
>>
>> I don't have any strong opinions on what should be in or out - but in
>> general it doesn't make sense to release things that aren't functional. At
>> the moment I'm not sure what those are - but I suspect not all of the
>> components are fully functional yet (for example transaction).
>>
>> Best Regards,
>> Joe
>>
>>
>> Jeremy Hughes wrote:
>>>
>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>> vacation until monday.
>>>
>>> Personally, I think the 0.1 release should serve to get what we have
>>> right now in the respectable form the ASF requires. So 'must haves'
>>> are to get the build in the right shape to create the distribution
>>> files that are acceptable to the IPMC. I think each main area of the
>>> code deserves at least a README to describe what's possible. Since
>>> this is the first release there are likely a few unknowns - w.r.t
>>> timing I hope/expect to get the release out this in feb. If there are
>>> particular JIRAs or other issues you feel should be included please
>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>> 0.2 version. WDYT?
>>>
>>> Cheers,
>>> Jeremy
>>>
>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>
>>>> Jeremy,
>>>>
>>>> What are your current thoughts and goals regarding the release and
>>>> potential
>>>> target dates?
>>>>
>>>> I think it would be good if you could summarize your thoughts in an email
>>>> or
>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>> progress.
>>>> Of particular interest would be the content that we would like to see in
>>>> the first release (clarifying what we consider "must have" from "nice to
>>>> have"), the current status of that content, target dates for the release,
>>>> and the process that we plan to use to generate the release.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>>
>>>>
>>>> Jeremy Hughes wrote:
>>>>>
>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>
>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>> on the wiki.
>>>>>
>>>>> Certainly will. It's been a while since I did one and the process has
>>>>> changed quite a bit :-)
>>>>>
>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>
>>>>>>> Jeremy
>>>>>>>
>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>> 0.1
>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>
>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>> step
>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>
>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>
>>>>>>>> --kevan
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>>
>>>> --
>>>> Joe
>>>>
>>>
>>
>>
>> --
>> Joe
>>
>
>
>
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
Guillaume Nodet wrote:
> I'd like to see at least those included:
> * blueprint
> * jmx
> * jndi
> * transaction
>
> I don't think applications are really usable yet and I haven't really
> looked at JPA yet, so can't tell about it.
> The transaction component is functional and we've been using it mostly
> unchanged since a long time in ServiceMix.
> Do you have any particular concerns with it ? (I'm not talking about
> declarative transactions for blueprint, note).
I have been specifically looking into leveraging declarative
transactions for the ariestrader sample and have not yet been successful
- so that was the basis of my comment.
>
> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>> Thanks for the response (even while on vacation!) ... and for volunteering
>> to be the release manager. Your response helps me get a better picture of
>> the plans.
>>
>> I was really just interested in the general objectives and timing since it
>> hadn't been discussed yet. To get the release out in Feb means it will be
>> delivered next week. I'm afraid the hill might be a little too steep to
>> climb that quickly but I'm happy to be proven wrong.
>>
>> The more communication the better. It's important to get everybody thinking
>> and planning along the same lines (or understand quickly if there are any
>> differences of opinion). Knowing that you are thinking of creating a
>> release candidate next week means that we should be getting more restrictive
>> on new content to avoid any unpleasant surprises.
>>
>> I don't have any strong opinions on what should be in or out - but in
>> general it doesn't make sense to release things that aren't functional. At
>> the moment I'm not sure what those are - but I suspect not all of the
>> components are fully functional yet (for example transaction).
>>
>> Best Regards,
>> Joe
>>
>>
>> Jeremy Hughes wrote:
>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>> vacation until monday.
>>>
>>> Personally, I think the 0.1 release should serve to get what we have
>>> right now in the respectable form the ASF requires. So 'must haves'
>>> are to get the build in the right shape to create the distribution
>>> files that are acceptable to the IPMC. I think each main area of the
>>> code deserves at least a README to describe what's possible. Since
>>> this is the first release there are likely a few unknowns - w.r.t
>>> timing I hope/expect to get the release out this in feb. If there are
>>> particular JIRAs or other issues you feel should be included please
>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>> 0.2 version. WDYT?
>>>
>>> Cheers,
>>> Jeremy
>>>
>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>> Jeremy,
>>>>
>>>> What are your current thoughts and goals regarding the release and
>>>> potential
>>>> target dates?
>>>>
>>>> I think it would be good if you could summarize your thoughts in an email
>>>> or
>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>> progress.
>>>> Of particular interest would be the content that we would like to see in
>>>> the first release (clarifying what we consider "must have" from "nice to
>>>> have"), the current status of that content, target dates for the release,
>>>> and the process that we plan to use to generate the release.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>>
>>>>
>>>> Jeremy Hughes wrote:
>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>> on the wiki.
>>>>> Certainly will. It's been a while since I did one and the process has
>>>>> changed quite a bit :-)
>>>>>
>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>> wrote:
>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>
>>>>>>> Jeremy
>>>>>>>
>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>> 0.1
>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>
>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>> step
>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>
>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>
>>>>>>>> --kevan
>>>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>> --
>>>> Joe
>>>>
>>
>> --
>> Joe
>>
>
>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 24 February 2010 03:44, Joe Bohn <jo...@gmail.com> wrote:
> David Jencks wrote:
>>
>> On Feb 23, 2010, at 5:13 PM, Alasdair Nottingham wrote:
>>
>>> I'm am new to maven, so sorry if I show my ignorance.
>>>
>>> While I think I can see the value to what you suggest moving forward if
>>> we choose to release sub-projects independantly (I say if because we haven't
>>> discussed or agreed what tbd long term answer is yet) I do not understand
>>> the benefit to a user of Aries of this change.
>>>
>>> As a result it does not appear to me to be key to resolve prior to
>>> release.
>>>
>>> I would like to understand the problems you see better, but I do not have
>>> the maven background you guys have, any chance you could explain what the
>>> problems are, why they are problems and the solution at some point?
>>
>> The biggest immediate problem is that without correct svn info you can't
>> do a release with the release plugin. I'm pretty sure the way its set up
>> now, when you try, the tag will be under maven's apache pom, not aries.
>> (you'll fail unless you happen to be a maven committer too). You definitely
>> don't want to try to do a release without the release plugin.
>>
>> Organizationally there's no way that for instance blueprint, application,
>> and samples should always be released in synchrony. Any time two of them
>> happen to be ready for release at the same time it will be purely
>> accidental. Right now everyone wants to get a milestone out the door, but
>> looking at the different projects their state of completion is pretty much
>> wildly different. A decision to release all of them at once is not based in
>> any way on them being equally complete. I'm suggesting that since build
>> fixes are needed anyway, why not set up a maintainable structure that will
>> continue to work beyond this publicity release. The benefit to users is
>> that aries will be able to release bits in a timely fashion; otherwise the
>> entire project will never be in a releasable state at once. (I'm only
>> exaggerating a little bit :-)
>>
>> What got me looking at this at all is what look like wild gyrations that
>> don't really use maven properly to get an .eba (or some artifact) out the
>> door. This might be ok for one release but (a) I think this can be done
>> directly with the assembly plugin short term and (b) an eba-maven-plugin
>> seems like the obvious more long term solution.
>>
>> I'm willing to fix the build and probably work on an eba plugin, but want
>> to be sure this is ok with everyone first.
>
>
> The svn info can be added to support the maven-release-plugin without
> reorganizing to support independent component releases. But I agree that it
> would be nice to have the option of independent releases even if we intend
> to release all components in this first release. So in general, I'm in
> favor of the reorganization.
I'm starting to come to the same conclusion. Flexibility is good. We
should have the ability to respond quickly to users who want a new
release of a subproject and not be forced into releasing the entirety
of Aries. So I'm +1 for a reorg to achieve this.
>
> As I mentioned earlier, I am concerned about the eba generation as well. I
> think a maven-eba-plugin would be preferred versus the alternative I
> mentioned of releasing the ebas simply as jars (again, assuming that the
> application code can deal with an archive of type jar instead of eba). I am
> using the maven-assembly-plugin to generate the jar for the eba in the
> AriesTrader sample but I didn't find the magic formula necessary to create
> the archive with a type of eba rather than jar and so I resorted to using
> ant (which I know is bad). A maven-eba-plugin or the necessary
> configuration to get the maven-release-plugin to generate something of type
> eba would sure be nice.
Yeah, resorting to ant made be barf too. I prefer a custom eba plugin
over the assembly plugin so we can add our own features more easily,
such as APPLICATION.MF generation.
>
> I guess the key question might be how long it would take to make these
> changes and is it worth the wait.
>
> Joe
>
>>
>> thanks
>> david jencks
>>
>>>
>>> Thanks
>>> Alasdair
>>>
>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com> wrote:
>>>
>>>> This discussion got me worried enough to take a look at the aries build.
>>>> Now I'm even more worried.
>>>>
>>>> While it might feel good to try to push out a release as fast as
>>>> possible I'd prefer to see a sustainable build system in place first. So
>>>> far it looks to me as if aries is going to be a bunch of loosely coupled
>>>> subprojects. Building them all at once is not going to work for long. I
>>>> think we should recognize that and put that in the build system now. To me
>>>> this means:
>>>>
>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>> 2. each subproject has pom info sufficient so it can be released (mostly
>>>> svn info) (right now this is completely missing everywhere as far as I can
>>>> see, which will result in ares getting tagged into svn as part of the apache
>>>> pom)
>>>>
>>>> We can still have a "fake" pom that builds everything, but it won't be
>>>> part of any release procedure.
>>>>
>>>> Having separately released subprojects does not prevent having a single
>>>> vote on all the releases.
>>>>
>>>> I'd suggest a few other pom tweaks such as using resources and
>>>> filtered-resources to distinguish when filtering is called for.
>>>>
>>>> In addition relevant to this particular bit of the thread, we need an
>>>> eba-maven-plugin to assemble ebas. Getting this into a first release would
>>>> be a great idea IMO.
>>>>
>>>> If there's general agreement I can spend some time playing with the
>>>> build and possibly working on the eba plugin.
>>>>
>>>> thoughts?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>
>>>>> Jeremy Hughes wrote:
>>>>>>
>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>
>>>>>>> I'd also like to see us release the sample applications but I think
>>>>>>> there is
>>>>>>> at least one complication. Both Blog Sample and AriesTrader generate
>>>>>>> EBAs
>>>>>>> using different techniques - but both leverage the
>>>>>>> maven-antrun-plugin to
>>>>>>> finally produce a file of type "eba".
>>>>>>
>>>>>> I realised the .eba file generated in the blog-assembly module wasn't
>>>>>> being pushed into my local repo. I've made some changes to the pom.xml
>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>>>>>> artifact and the build-helper-maven-plugin to push the artifact to the
>>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba for
>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>
>>>>> I've not used the build-helper-maven-plugin before. Do you know if it
>>>>> will work with the maven-release-plugin to push the eba artifacts when we do
>>>>> a release? If so, then I should look at using the same mechanism for
>>>>> AriesTrader.
>>>>>
>>>>>>> I think the result is that the eba will not be available in a maven
>>>>>>> repository.
>>>>>>>
>>>>>>> One of the differences is that AriesTrader first generates a jar
>>>>>>> using the
>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar will
>>>>>>> be
>>>>>>> managed by maven and IIUC it should be deployable as an "application"
>>>>>>> even
>>>>>>> with an extension of "jar" rather than "eba". If that is correct
>>>>>>> then
>>>>>>> perhaps delivery of an application jar is an acceptable approach for
>>>>>>> the 1st
>>>>>>> release. Unfortunately I haven't actually setup my equinox assembly
>>>>>>> to
>>>>>>> deploy the eba yet - it still deploys all of the individual bundles.
>>>>>>
>>>>>> Using the maven-assembly-plugin likely the preferred approach long
>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>> control and add the .eba one?
>>>>>
>>>>> I can give this a try for AriesTrader. If it doesn't work out - is
>>>>> there anything wrong with the approach I mentioned earlier of just using the
>>>>> jar artifacts rather than the eba artifacts? Will the current application
>>>>> support only look at *.eba archives?
>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Guillaume Nodet wrote:
>>>>>>>>
>>>>>>>> I'd like to see at least those included:
>>>>>>>> * blueprint
>>>>>>>> * jmx
>>>>>>>> * jndi
>>>>>>>> * transaction
>>>>>>>>
>>>>>>>> I don't think applications are really usable yet and I haven't
>>>>>>>> really
>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>> The transaction component is functional and we've been using it
>>>>>>>> mostly
>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>> Do you have any particular concerns with it ? (I'm not talking about
>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>
>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>> volunteering
>>>>>>>>> to be the release manager. Your response helps me get a better
>>>>>>>>> picture
>>>>>>>>> of
>>>>>>>>> the plans.
>>>>>>>>>
>>>>>>>>> I was really just interested in the general objectives and timing
>>>>>>>>> since
>>>>>>>>> it
>>>>>>>>> hadn't been discussed yet. To get the release out in Feb means it
>>>>>>>>> will
>>>>>>>>> be
>>>>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>>>>> steep to
>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>
>>>>>>>>> The more communication the better. It's important to get everybody
>>>>>>>>> thinking
>>>>>>>>> and planning along the same lines (or understand quickly if there
>>>>>>>>> are any
>>>>>>>>> differences of opinion). Knowing that you are thinking of creating
>>>>>>>>> a
>>>>>>>>> release candidate next week means that we should be getting more
>>>>>>>>> restrictive
>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>
>>>>>>>>> I don't have any strong opinions on what should be in or out - but
>>>>>>>>> in
>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>> functional.
>>>>>>>>> At
>>>>>>>>> the moment I'm not sure what those are - but I suspect not all of
>>>>>>>>> the
>>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out
>>>>>>>>>> on
>>>>>>>>>> vacation until monday.
>>>>>>>>>>
>>>>>>>>>> Personally, I think the 0.1 release should serve to get what we
>>>>>>>>>> have
>>>>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>>>>> haves'
>>>>>>>>>> are to get the build in the right shape to create the distribution
>>>>>>>>>> files that are acceptable to the IPMC. I think each main area of
>>>>>>>>>> the
>>>>>>>>>> code deserves at least a README to describe what's possible. Since
>>>>>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>>>>>> timing I hope/expect to get the release out this in feb. If there
>>>>>>>>>> are
>>>>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>>>>> please
>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>>>>>> target
>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a
>>>>>>>>>> new
>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Jeremy
>>>>>>>>>>
>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Jeremy,
>>>>>>>>>>>
>>>>>>>>>>> What are your current thoughts and goals regarding the release
>>>>>>>>>>> and
>>>>>>>>>>> potential
>>>>>>>>>>> target dates?
>>>>>>>>>>>
>>>>>>>>>>> I think it would be good if you could summarize your thoughts in
>>>>>>>>>>> an
>>>>>>>>>>> email
>>>>>>>>>>> or
>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>>>>>>> progress.
>>>>>>>>>>> Of particular interest would be the content that we would like to
>>>>>>>>>>> see
>>>>>>>>>>> in
>>>>>>>>>>> the first release (clarifying what we consider "must have" from
>>>>>>>>>>> "nice
>>>>>>>>>>> to
>>>>>>>>>>> have"), the current status of that content, target dates for the
>>>>>>>>>>> release,
>>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>> I guess if you take some notes, it would be interesting to put
>>>>>>>>>>>>> those
>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>
>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>> process has
>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>> components at a
>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>> scheme, IMO.
>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joe
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Joe
>>>>
>>
>>
>
>
> --
> Joe
>
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
On Mar 2, 2010, at 2:40 PM, Jeremy Hughes wrote:
> On 2 March 2010 19:30, Joe Bohn <jo...@gmail.com> wrote:
>> Thanks David.
>>
>> After I sent my last note I recalled another place in AriesTrader
>> with
>> hard-coded versions. The APPLICATION.MF files used for the two
>> EBAs that
>> are generated includes the bundle version - which is a little
>> different than
>> the maven version. Where the maven version is currently
>> 1.0.0-incubating-SNAPSHOT the bundle version generated using the
>> maven-bundle-plugin is 1.0.0.incubating-SNAPSHOT to conform to the
>> OSGi
>> version scheme.
>
> Are you saying we couldn't quite generate the APPLICATION.MF using
> resource filtering because the ${version} will be
> 1.0.0-incubating-SNAPSHOT instead of 1.0.0.incubating-SNAPSHOT?
That wouldn't be a problem, but I'm not sure if the eba-maven-plugin
is filtering the (supplied) application.mf at the moment. We might
need to fix that.
>
>>
>> There are two things which might make this a moot point:
>> 1) If the eba-maven-plugin is enhanced to generate the
>> APPLICATION.MF then
>> we can use that to resolve the issue.
>
> Yes I agree eba-maven-plugin should pull the same trick as the
> maven-bundle-plugin to ensure version numbers fit with the OSGi spec
> (whatever the logic for that conversion is).
That's going to take a little more help... would take me some thought.
thanks
david jencks
>
>> 2) Even though this is an issue with SNAPSHOTs I imagine it isn't
>> an issue
>> with a non-snapshot release because it won't container the "-XXX"
>> qualification.
>
> I think it'll continue to be an issue while we are using the -
> incubating suffix.
>
>>
>> Optionally, I could also just omit the APPLICATION.MF altogether
>> from the
>> AriesTrader EBAs since I understand that it is not required. That
>> might be
>> quickest fix for now.
>
> Do all the AriesTrader .eba files contain, by value, all the bundles
> they need? And, is that set transitively closed? If so then you
> certainly could remove the APPLICATION.MF. Or is it using the OBR
> resolver integration code to pull in bundles from a repository?
>
>>
>> Joe
>>
>> David Jencks wrote:
>>>
>>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>>>
>>>> I agree that we should make a global change to 0.1-incubating-
>>>> SNAPSHOT
>>>> first. Why wouldn't we just do that now?
>>>
>>> I started doing some experiments here...
>>>
>>> running
>>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>>>
>>> in root and parent upgrades everything maven knows about just fine.
>>> However there's (1) mentioned below and also a hardcoded version
>>> in two
>>> blueprint-itests.
>>>
>>> According to
>>>
>>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>>>
>>> we should be able to replace the hardcoded versions with
>>> .versionAsInProject()
>>>
>>> if we run the maven-paxexam-plugin on the project. However I can't
>>> get it
>>> to work yet.
>>>>
>>>> Just a heads-up on some other issues related to versions in
>>>> samples.
>>>> There are two potential problems that I am aware of:
>>>>
>>>> 1) For both Blog-Sample and AriesTrader there are hard-coded
>>>> version
>>>> references in the Equinox assembly config.ini file which are used
>>>> to specify
>>>> the bundle jars that are to be started for the assembly.
>>>> Naturally, the
>>>> versions of the aries bundles in this file won't be updated by the
>>>> maven-release-plugin. I'm not sure of a good solution for this
>>>> beyond just
>>>> manually changing the config.ini files prior to creating a release
>>>> candidate.
>>>
>>> I think we might be able to work around this by putting the
>>> config.ini
>>> files in src/main/resources/filtered-resources and defining a
>>> bunch of
>>> properties in an appropriate pom and using them for the version
>>> imports of
>>> the aries subproject dependencyManagement imports in the samples
>>> root pom.
>>> I haven't tried this yet...
>>>
>>>>
>>>> 2) I think there is still an unresolved issue related to Blog-
>>>> Sample and
>>>> how we might be able to demonstrate a bundle upgrade scenario.
>>>> I'm not
>>>> sure if this capability is included yet in Blog-Sample - so it
>>>> might still
>>>> be a non-issue at the moment. However, we had some discussion on
>>>> this a
>>>> week ago or so related to how we might be able to include
>>>> multiple versions
>>>> of components in the sample so that an upgrade scenario could be
>>>> demonstrated. If that is still a goal for the 0.1 release we
>>>> will need to
>>>> come up with some solution.
>>>
>>> no ideas from me on this one :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Joe
>>>>
>>>>
>>>> David Jencks wrote:
>>>>>
>>>>> I think everything is ok.... I think (at least with dryRun=true)
>>>>> that
>>>>> the release plugin builds the project first as-is and checks
>>>>> that signing
>>>>> etc works.
>>>>> I added autoVersionSubmodules=true in the root parent pom which
>>>>> will
>>>>> make things work more smoothly :-)
>>>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>>>>> first, I'm happy to do this if you want.
>>>>> thanks
>>>>> david jencks
>>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>>>
>>>>>> scratch that. I'm working thru this:
>>>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>>>> there's several steps I haven't done.
>>>>>>
>>>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>>>
>>>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I've done most of what I think is needed for aries to be
>>>>>>>> basically
>>>>>>>> releasable. There are some bits left and possibly stuff I've
>>>>>>>> missed.
>>>>>>>>
>>>>>>>> 1. legal file review. There are a bunch of NOTICE files that
>>>>>>>> claim
>>>>>>>> that
>>>>>>>> work from osgi is included. Really? license and notice
>>>>>>>> files are
>>>>>>>> supposed
>>>>>>>> to apply to what is actually in an artifact or checkout. Are
>>>>>>>> some of
>>>>>>>> our
>>>>>>>> source files copied from an osgi source? Also all the legal
>>>>>>>> files
>>>>>>>> that end
>>>>>>>> up in binary artifacts need to be checked. Also we need to
>>>>>>>> run the
>>>>>>>> rat
>>>>>>>> plugin: this should be configured in the default pom. Not
>>>>>>>> sure if I
>>>>>>>> will
>>>>>>>> get to this.
>>>>>>>>
>>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure
>>>>>>>> how to
>>>>>>>> make
>>>>>>>> sure that an eba is working so I didn't mess with this. I
>>>>>>>> think the
>>>>>>>> plugin
>>>>>>>> itself is working well enough to use though.
>>>>>>>>
>>>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>>>> convenient to
>>>>>>>> have these alphabetized so I can find what I'm looking for,
>>>>>>>> but I
>>>>>>>> haven't
>>>>>>>> done this in most poms. I'm not sure why there isn't a
>>>>>>>> usable tool
>>>>>>>> for
>>>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>>>
>>>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>>>> dependency:analyze and
>>>>>>>> look carefully at the results. The results from this can
>>>>>>>> require
>>>>>>>> interpretation so its best if someone who is very familiar
>>>>>>>> with how
>>>>>>>> the code
>>>>>>>> works does this.
>>>>>>>>
>>>>>>>> 4. before a release all snapshots need to be resolved to
>>>>>>>> released
>>>>>>>> versions.
>>>>>>>> I don't know if there are any snapshots.
>>>>>>>>
>>>>>>>> To summarize what I've tried to do:
>>>>>>>>
>>>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>>>> dependencies
>>>>>>>> that all projects are pretty sure to use including the pax
>>>>>>>> stuff used
>>>>>>>> mostly
>>>>>>>> for testing.
>>>>>>>>
>>>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>>>
>>>>>>>> 3. each subproject has an scm element in its pom, but no
>>>>>>>> others do.
>>>>>>>>
>>>>>>>> 4. each subproject has dependency management for everything
>>>>>>>> included
>>>>>>>> in it.
>>>>>>>> In addition, it has its subprojects listed in dependency
>>>>>>>> management.
>>>>>>>> (this
>>>>>>>> is bent slightly for the samples). This means that
>>>>>>>> (a) modules in a subproject don't need to include versions
>>>>>>>> for use of
>>>>>>>> other
>>>>>>>> modules
>>>>>>>> (b) you can get dependency management for all the modules in a
>>>>>>>> subproject
>>>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>>>> samples pom
>>>>>>>> for an example).
>>>>>>>>
>>>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>>>> dependency
>>>>>>>> elements.
>>>>>>>>
>>>>>>>> Release is going to involve...
>>>>>>>>
>>>>>>>> releasing the parent
>>>>>>>
>>>>>>> In trunk/parent I tried:
>>>>>>>
>>>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>>>
>>>>>>> Providing 0.1-incubating for the release version
>>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development
>>>>>>> version
>>>>>>>
>>>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>>>
>>>>>>> [INFO] [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>>>> [INFO] [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>> [INFO] [INFO] [clean:clean]
>>>>>>> [INFO] [INFO] Setting property:
>>>>>>> classpath.resource.loader.class =>
>>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on =>
>>>>>>> 'false'.
>>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>>>> 'false'.
>>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>>>> [INFO] [INFO] [assembly:single {execution: source-release-
>>>>>>> assembly}]
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>> added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>>> added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] Building zip:
>>>>>>>
>>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target
>>>>>>> \parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>> added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>>> added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] Preparing source:jar
>>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>>>> recursive invocation.
>>>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>>>> classpath-capable package
>>>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>>>
>>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>>>
>>>>>>> Then stops at the gpg stage. I thought it would prompt me for
>>>>>>> my key
>>>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>>>
>>>>>>>> updating the parent version wherever it is used (all subproject
>>>>>>>> parents)
>>>>>>>>
>>>>>>>> releasing the subprojects in an appropriate order and
>>>>>>>> updating their
>>>>>>>> versions wherever they are used.
>>>>>>>>
>>>>>>>> It might be worthwhile changing the pom version to
>>>>>>>> 0.1-incubating-SNAPSHOT
>>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing
>>>>>>>> this
>>>>>>>> because
>>>>>>>> then the versions plugin can be used to update use of a
>>>>>>>> subproject to
>>>>>>>> the
>>>>>>>> newly released version of what it uses. Going from
>>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>>>
>>>>>>>> As noted in the "root" pom, don't try to release the root pom
>>>>>>>> and
>>>>>>>> don't try
>>>>>>>> release everything at once from the root pom.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> I started looking into cleaning up the build, and of course
>>>>>>>>> it is
>>>>>>>>> taking
>>>>>>>>> longer than I expected.
>>>>>>>>>
>>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>>>
>>>>>>>>> There are some projects in application that stop compiling
>>>>>>>>> if you
>>>>>>>>> alphabetize the dependencies. It looks like osgi 3
>>>>>>>>> artifacts are
>>>>>>>>> getting on
>>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding
>>>>>>>>> exclusions to
>>>>>>>>> the
>>>>>>>>> dependencies seems to fix it if you can figure out where the
>>>>>>>>> out of
>>>>>>>>> date
>>>>>>>>> jars are coming from.
>>>>>>>>>
>>>>>>>>> The build is already much closer to a multi-release model
>>>>>>>>> than a
>>>>>>>>> single
>>>>>>>>> release model.
>>>>>>>>>
>>>>>>>>> I've diffed what I have so far and attached it to
>>>>>>>>> ARIES-173. It
>>>>>>>>> includes
>>>>>>>>> scm info and a lot of version corrections. Due to the
>>>>>>>>> failing tests
>>>>>>>>> I'm not
>>>>>>>>> too comfortable committing it.
>>>>>>>>>
>>>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> It 'd be great if you are willing to fix these build
>>>>>>>>>> issues, since
>>>>>>>>>> you
>>>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>>>
>>>>>>>>>> I know the maven release plugin isn't friendly to use some
>>>>>>>>>> cases,
>>>>>>>>>> so
>>>>>>>>>> it is best we get these resolved to make our release
>>>>>>>>>> process a bit
>>>>>>>>>> easier.
>>>>>>>>>>
>>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time
>>>>>>>>>> with
>>>>>>>>>> the
>>>>>>>>>> release.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Lin
>>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>>>> <da...@yahoo.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I would like to understand the problems you see better,
>>>>>>>>>>>> but I do
>>>>>>>>>>>> not
>>>>>>>>>>>> have
>>>>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>>>>> explain
>>>>>>>>>>>> what
>>>>>>>>>>>> the
>>>>>>>>>>>> problems are, why they are problems and the solution at
>>>>>>>>>>>> some
>>>>>>>>>>>> point?
>>>>>>>>>>>
>>>>>>>>>>> The biggest immediate problem is that without correct svn
>>>>>>>>>>> info you
>>>>>>>>>>> can't
>>>>>>>>>>> do
>>>>>>>>>>> a release with the release plugin. I'm pretty sure the
>>>>>>>>>>> way its
>>>>>>>>>>> set up
>>>>>>>>>>> now,
>>>>>>>>>>> when you try, the tag will be under maven's apache pom,
>>>>>>>>>>> not aries.
>>>>>>>>>>> (you'll
>>>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>>>> definitely
>>>>>>>>>>> don't
>>>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>>>
>>>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>>>> application,
>>>>>>>>>>> and samples should always be released in synchrony. Any
>>>>>>>>>>> time two
>>>>>>>>>>> of
>>>>>>>>>>> them
>>>>>>>>>>> happen to be ready for release at the same time it will be
>>>>>>>>>>> purely
>>>>>>>>>>> accidental. Right now everyone wants to get a milestone
>>>>>>>>>>> out the
>>>>>>>>>>> door,
>>>>>>>>>>> but
>>>>>>>>>>> looking at the different projects their state of
>>>>>>>>>>> completion is
>>>>>>>>>>> pretty
>>>>>>>>>>> much
>>>>>>>>>>> wildly different. A decision to release all of them at
>>>>>>>>>>> once is
>>>>>>>>>>> not
>>>>>>>>>>> based in
>>>>>>>>>>> any way on them being equally complete. I'm suggesting
>>>>>>>>>>> that since
>>>>>>>>>>> build
>>>>>>>>>>> fixes are needed anyway, why not set up a maintainable
>>>>>>>>>>> structure
>>>>>>>>>>> that
>>>>>>>>>>> will
>>>>>>>>>>> continue to work beyond this publicity release. The
>>>>>>>>>>> benefit to
>>>>>>>>>>> users is
>>>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>>>> otherwise
>>>>>>>>>>> the
>>>>>>>>>>> entire project will never be in a releasable state at
>>>>>>>>>>> once. (I'm
>>>>>>>>>>> only
>>>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>>>
>>>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>>>> gyrations that
>>>>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>>>>> artifact)
>>>>>>>>>>> out
>>>>>>>>>>> the
>>>>>>>>>>> door. This might be ok for one release but (a) I think
>>>>>>>>>>> this can
>>>>>>>>>>> be done
>>>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>>>> eba-maven-plugin
>>>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>>>
>>>>>>>>>>> I'm willing to fix the build and probably work on an eba
>>>>>>>>>>> plugin,
>>>>>>>>>>> but
>>>>>>>>>>> want to
>>>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Alasdair
>>>>>>>>>>>>
>>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <david_jencks@yahoo.com
>>>>>>>>>>>> >
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> This discussion got me worried enough to take a look at
>>>>>>>>>>>>> the
>>>>>>>>>>>>> aries
>>>>>>>>>>>>> build.
>>>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>>>
>>>>>>>>>>>>> While it might feel good to try to push out a release as
>>>>>>>>>>>>> fast as
>>>>>>>>>>>>> possible
>>>>>>>>>>>>> I'd prefer to see a sustainable build system in place
>>>>>>>>>>>>> first. So
>>>>>>>>>>>>> far
>>>>>>>>>>>>> it
>>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>>>> coupled
>>>>>>>>>>>>> subprojects. Building them all at once is not going to
>>>>>>>>>>>>> work for
>>>>>>>>>>>>> long.
>>>>>>>>>>>>> I
>>>>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>>>>> system
>>>>>>>>>>>>> now.
>>>>>>>>>>>>> To me
>>>>>>>>>>>>> this means:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>>>>>>> released
>>>>>>>>>>>>> (mostly
>>>>>>>>>>>>> svn info) (right now this is completely missing
>>>>>>>>>>>>> everywhere as
>>>>>>>>>>>>> far as
>>>>>>>>>>>>> I can
>>>>>>>>>>>>> see, which will result in ares getting tagged into svn
>>>>>>>>>>>>> as part
>>>>>>>>>>>>> of the
>>>>>>>>>>>>> apache
>>>>>>>>>>>>> pom)
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can still have a "fake" pom that builds everything,
>>>>>>>>>>>>> but it
>>>>>>>>>>>>> won't be
>>>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Having separately released subprojects does not prevent
>>>>>>>>>>>>> having a
>>>>>>>>>>>>> single
>>>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using
>>>>>>>>>>>>> resources and
>>>>>>>>>>>>> filtered-resources to distinguish when filtering is
>>>>>>>>>>>>> called for.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In addition relevant to this particular bit of the
>>>>>>>>>>>>> thread, we
>>>>>>>>>>>>> need an
>>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a
>>>>>>>>>>>>> first
>>>>>>>>>>>>> release
>>>>>>>>>>>>> would
>>>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If there's general agreement I can spend some time
>>>>>>>>>>>>> playing with
>>>>>>>>>>>>> the
>>>>>>>>>>>>> build
>>>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thoughts?
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn
>>>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd also like to see us release the sample
>>>>>>>>>>>>>>>> applications but I
>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and
>>>>>>>>>>>>>>>> AriesTrader
>>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I realised the .eba file generated in the blog-
>>>>>>>>>>>>>>> assembly module
>>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>>> being pushed into my local repo. I've made some
>>>>>>>>>>>>>>> changes to the
>>>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to
>>>>>>>>>>>>>>> create the
>>>>>>>>>>>>>>> .eba
>>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files
>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>> .eba for
>>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do
>>>>>>>>>>>>>> you
>>>>>>>>>>>>>> know if
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>>> when we do
>>>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>>>> mechanism for
>>>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think the result is that the eba will not be
>>>>>>>>>>>>>>>> available in a
>>>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One of the differences is that AriesTrader first
>>>>>>>>>>>>>>>> generates a
>>>>>>>>>>>>>>>> jar
>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an
>>>>>>>>>>>>>>>> eba. The
>>>>>>>>>>>>>>>> jar will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If
>>>>>>>>>>>>>>>> that is
>>>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my
>>>>>>>>>>>>>>>> equinox
>>>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the
>>>>>>>>>>>>>>>> individual
>>>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and
>>>>>>>>>>>>>>> use the
>>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact
>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't
>>>>>>>>>>>>>> work out
>>>>>>>>>>>>>> - is
>>>>>>>>>>>>>> there anything wrong with the approach I mentioned
>>>>>>>>>>>>>> earlier of
>>>>>>>>>>>>>> just
>>>>>>>>>>>>>> using the
>>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the
>>>>>>>>>>>>>> current
>>>>>>>>>>>>>> application
>>>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>>>> The transaction component is functional and we've
>>>>>>>>>>>>>>>>> been using
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <joebohn@gmail.com
>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks for the response (even while on
>>>>>>>>>>>>>>>>>> vacation!) ... and
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me
>>>>>>>>>>>>>>>>>> get a
>>>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I was really just interested in the general
>>>>>>>>>>>>>>>>>> objectives and
>>>>>>>>>>>>>>>>>> timing
>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out
>>>>>>>>>>>>>>>>>> in Feb
>>>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be
>>>>>>>>>>>>>>>>>> a little
>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The more communication the better. It's important
>>>>>>>>>>>>>>>>>> to get
>>>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>>> and planning along the same lines (or understand
>>>>>>>>>>>>>>>>>> quickly if
>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are
>>>>>>>>>>>>>>>>>> thinking of
>>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be
>>>>>>>>>>>>>>>>>> in or
>>>>>>>>>>>>>>>>>> out -
>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> general it doesn't make sense to release things
>>>>>>>>>>>>>>>>>> that aren't
>>>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I
>>>>>>>>>>>>>>>>>> suspect not
>>>>>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday
>>>>>>>>>>>>>>>>>>> but am
>>>>>>>>>>>>>>>>>>> now out
>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve
>>>>>>>>>>>>>>>>>>> to get
>>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF
>>>>>>>>>>>>>>>>>>> requires. So
>>>>>>>>>>>>>>>>>>> 'must
>>>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think
>>>>>>>>>>>>>>>>>>> each main
>>>>>>>>>>>>>>>>>>> area of
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>>>>> unknowns
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this
>>>>>>>>>>>>>>>>>>> in feb.
>>>>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version
>>>>>>>>>>>>>>>>>>> 1.0 to
>>>>>>>>>>>>>>>>>>> 0.1 and
>>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for
>>>>>>>>>>>>>>>>>>> 0.1 to
>>>>>>>>>>>>>>>>>>> target a
>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <joebohn@gmail.com
>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals
>>>>>>>>>>>>>>>>>>>> regarding the
>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize
>>>>>>>>>>>>>>>>>>>> your
>>>>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep
>>>>>>>>>>>>>>>>>>>> updated as
>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that
>>>>>>>>>>>>>>>>>>>> we would
>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider
>>>>>>>>>>>>>>>>>>>> "must
>>>>>>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> have"), the current status of that content,
>>>>>>>>>>>>>>>>>>>> target dates
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need
>>>>>>>>>>>>>>>>>>>>>> any help.
>>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>>>>> interesting
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did
>>>>>>>>>>>>>>>>>>>>> one and
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release
>>>>>>>>>>>>>>>>>>>>>>> manager.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release
>>>>>>>>>>>>>>>>>>>>>>>> with all
>>>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint
>>>>>>>>>>>>>>>>>>>>>>>> release as
>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache
>>>>>>>>>>>>>>>>>>>>>>>> release is
>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to
>>>>>>>>>>>>>>>>>>>>>>>> see this
>>>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>> --
>>>> Joe
>>>
>>>
>>
>>
>> --
>> Joe
>>
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
Cool.
Just FYI, when this topic was originally raised it was in the context of
the APPLICATION.MF where we were attempting to substitute the version in
a hard-coded APPLICATION.MF when generating the EBA. Since that time
the eba-maven-plugin was introduced which will automatically generate
the complete APPLICATION.MF. This is what we are now using in the samples.
Joe
Guillaume Nodet wrote:
> FWIW, I've added to the latest maven bundle plugin a goal that can be used
> to transform a string into a correct osgi version.
> The goal is now run automatically in the aries build and you can use the
> aries.osgi.version.clean property to obtain the correct syntax corresponding
> to the maven version.
>
>
> On Wed, Mar 3, 2010 at 18:48, Joe Bohn <jo...@gmail.com> wrote:
>
>> Sorry, I thought I replied to this yesterday but see that I didn't.
>>
>>
>> Jeremy Hughes wrote:
>>
>>> On 2 March 2010 19:30, Joe Bohn <jo...@gmail.com> wrote:
>>>
>>>> Thanks David.
>>>>
>>>> After I sent my last note I recalled another place in AriesTrader with
>>>> hard-coded versions. The APPLICATION.MF files used for the two EBAs
>>>> that
>>>> are generated includes the bundle version - which is a little different
>>>> than
>>>> the maven version. Where the maven version is currently
>>>> 1.0.0-incubating-SNAPSHOT the bundle version generated using the
>>>> maven-bundle-plugin is 1.0.0.incubating-SNAPSHOT to conform to the OSGi
>>>> version scheme.
>>>>
>>> Are you saying we couldn't quite generate the APPLICATION.MF using
>>> resource filtering because the ${version} will be
>>> 1.0.0-incubating-SNAPSHOT instead of 1.0.0.incubating-SNAPSHOT?
>>>
>> Not necessarily. It's just that we'll need to keep the different format in
>> mind.
>>
>>
>>
>>> There are two things which might make this a moot point:
>>>> 1) If the eba-maven-plugin is enhanced to generate the APPLICATION.MF
>>>> then
>>>> we can use that to resolve the issue.
>>>>
>>> Yes I agree eba-maven-plugin should pull the same trick as the
>>> maven-bundle-plugin to ensure version numbers fit with the OSGi spec
>>> (whatever the logic for that conversion is).
>>>
>> Yes.
>>
>>
>>
>>> 2) Even though this is an issue with SNAPSHOTs I imagine it isn't an
>>>> issue
>>>> with a non-snapshot release because it won't container the "-XXX"
>>>> qualification.
>>>>
>>> I think it'll continue to be an issue while we are using the -incubating
>>> suffix.
>>>
>> Agreed. I wasn't sure if we were releasing 0.1 or 0.1-incubating.
>>
>>
>>
>>> Optionally, I could also just omit the APPLICATION.MF altogether from the
>>>> AriesTrader EBAs since I understand that it is not required. That might
>>>> be
>>>> quickest fix for now.
>>>>
>>> Do all the AriesTrader .eba files contain, by value, all the bundles
>>> they need? And, is that set transitively closed? If so then you
>>> certainly could remove the APPLICATION.MF. Or is it using the OBR
>>> resolver integration code to pull in bundles from a repository?
>>>
>> At the moment the eba includes the complete set of bundles by value.
>> However, I'm not sure if that will always be the case (or even if it will be
>> the case in all environments for some of the dependencies, such as slf4j).
>> I'll experiment a bit.
>>
>>
>>
>>> Joe
>>>> David Jencks wrote:
>>>>
>>>>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>>>>>
>>>>> I agree that we should make a global change to 0.1-incubating-SNAPSHOT
>>>>>> first. Why wouldn't we just do that now?
>>>>>>
>>>>> I started doing some experiments here...
>>>>>
>>>>> running
>>>>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>>>>>
>>>>> in root and parent upgrades everything maven knows about just fine.
>>>>> However there's (1) mentioned below and also a hardcoded version in two
>>>>> blueprint-itests.
>>>>>
>>>>> According to
>>>>>
>>>>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>>>>>
>>>>> we should be able to replace the hardcoded versions with
>>>>> .versionAsInProject()
>>>>>
>>>>> if we run the maven-paxexam-plugin on the project. However I can't get
>>>>> it
>>>>> to work yet.
>>>>>
>>>>>> Just a heads-up on some other issues related to versions in samples.
>>>>>> There are two potential problems that I am aware of:
>>>>>>
>>>>>> 1) For both Blog-Sample and AriesTrader there are hard-coded version
>>>>>> references in the Equinox assembly config.ini file which are used to
>>>>>> specify
>>>>>> the bundle jars that are to be started for the assembly. Naturally, the
>>>>>> versions of the aries bundles in this file won't be updated by the
>>>>>> maven-release-plugin. I'm not sure of a good solution for this beyond
>>>>>> just
>>>>>> manually changing the config.ini files prior to creating a release
>>>>>> candidate.
>>>>>>
>>>>> I think we might be able to work around this by putting the config.ini
>>>>> files in src/main/resources/filtered-resources and defining a bunch of
>>>>> properties in an appropriate pom and using them for the version imports
>>>>> of
>>>>> the aries subproject dependencyManagement imports in the samples root
>>>>> pom.
>>>>> I haven't tried this yet...
>>>>>
>>>>> 2) I think there is still an unresolved issue related to Blog-Sample
>>>>>> and
>>>>>> how we might be able to demonstrate a bundle upgrade scenario. I'm
>>>>>> not
>>>>>> sure if this capability is included yet in Blog-Sample - so it might
>>>>>> still
>>>>>> be a non-issue at the moment. However, we had some discussion on this
>>>>>> a
>>>>>> week ago or so related to how we might be able to include multiple
>>>>>> versions
>>>>>> of components in the sample so that an upgrade scenario could be
>>>>>> demonstrated. If that is still a goal for the 0.1 release we will need
>>>>>> to
>>>>>> come up with some solution.
>>>>>>
>>>>> no ideas from me on this one :-)
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> Joe
>>>>>>
>>>>>> David Jencks wrote:
>>>>>>
>>>>>>> I think everything is ok.... I think (at least with dryRun=true) that
>>>>>>> the release plugin builds the project first as-is and checks that
>>>>>>> signing
>>>>>>> etc works.
>>>>>>> I added autoVersionSubmodules=true in the root parent pom which will
>>>>>>> make things work more smoothly :-)
>>>>>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>>>>>>> first, I'm happy to do this if you want.
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>>>>
>>>>>>>> scratch that. I'm working thru this:
>>>>>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>>>>>> there's several steps I haven't done.
>>>>>>>>
>>>>>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>>>>
>>>>>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>> I've done most of what I think is needed for aries to be basically
>>>>>>>>>> releasable. There are some bits left and possibly stuff I've
>>>>>>>>>> missed.
>>>>>>>>>>
>>>>>>>>>> 1. legal file review. There are a bunch of NOTICE files that claim
>>>>>>>>>> that
>>>>>>>>>> work from osgi is included. Really? license and notice files are
>>>>>>>>>> supposed
>>>>>>>>>> to apply to what is actually in an artifact or checkout. Are some
>>>>>>>>>> of
>>>>>>>>>> our
>>>>>>>>>> source files copied from an osgi source? Also all the legal files
>>>>>>>>>> that end
>>>>>>>>>> up in binary artifacts need to be checked. Also we need to run the
>>>>>>>>>> rat
>>>>>>>>>> plugin: this should be configured in the default pom. Not sure if
>>>>>>>>>> I
>>>>>>>>>> will
>>>>>>>>>> get to this.
>>>>>>>>>>
>>>>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how
>>>>>>>>>> to
>>>>>>>>>> make
>>>>>>>>>> sure that an eba is working so I didn't mess with this. I think
>>>>>>>>>> the
>>>>>>>>>> plugin
>>>>>>>>>> itself is working well enough to use though.
>>>>>>>>>>
>>>>>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>>>>>> convenient to
>>>>>>>>>> have these alphabetized so I can find what I'm looking for, but I
>>>>>>>>>> haven't
>>>>>>>>>> done this in most poms. I'm not sure why there isn't a usable tool
>>>>>>>>>> for
>>>>>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>>>>>
>>>>>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>>>>>> dependency:analyze and
>>>>>>>>>> look carefully at the results. The results from this can require
>>>>>>>>>> interpretation so its best if someone who is very familiar with how
>>>>>>>>>> the code
>>>>>>>>>> works does this.
>>>>>>>>>>
>>>>>>>>>> 4. before a release all snapshots need to be resolved to released
>>>>>>>>>> versions.
>>>>>>>>>> I don't know if there are any snapshots.
>>>>>>>>>>
>>>>>>>>>> To summarize what I've tried to do:
>>>>>>>>>>
>>>>>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>>>>>> dependencies
>>>>>>>>>> that all projects are pretty sure to use including the pax stuff
>>>>>>>>>> used
>>>>>>>>>> mostly
>>>>>>>>>> for testing.
>>>>>>>>>>
>>>>>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>>>>>
>>>>>>>>>> 3. each subproject has an scm element in its pom, but no others do.
>>>>>>>>>>
>>>>>>>>>> 4. each subproject has dependency management for everything
>>>>>>>>>> included
>>>>>>>>>> in it.
>>>>>>>>>> In addition, it has its subprojects listed in dependency
>>>>>>>>>> management.
>>>>>>>>>> (this
>>>>>>>>>> is bent slightly for the samples). This means that
>>>>>>>>>> (a) modules in a subproject don't need to include versions for use
>>>>>>>>>> of
>>>>>>>>>> other
>>>>>>>>>> modules
>>>>>>>>>> (b) you can get dependency management for all the modules in a
>>>>>>>>>> subproject
>>>>>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>>>>>> samples pom
>>>>>>>>>> for an example).
>>>>>>>>>>
>>>>>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>>>>>> dependency
>>>>>>>>>> elements.
>>>>>>>>>>
>>>>>>>>>> Release is going to involve...
>>>>>>>>>>
>>>>>>>>>> releasing the parent
>>>>>>>>>>
>>>>>>>>> In trunk/parent I tried:
>>>>>>>>>
>>>>>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>>>>>
>>>>>>>>> Providing 0.1-incubating for the release version
>>>>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development
>>>>>>>>> version
>>>>>>>>>
>>>>>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>>>>>
>>>>>>>>> [INFO] [INFO]
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>>>>>> [INFO] [INFO]
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------
>>>>>>>>> [INFO] [INFO] [clean:clean]
>>>>>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>>>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>>>>>> 'false'.
>>>>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>>>>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>>>> skipping
>>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>>>> added,
>>>>>>>>> skipping
>>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>>>>>>>> skipping
>>>>>>>>> [INFO] [INFO] Building zip:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>>>> skipping
>>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>>>> added,
>>>>>>>>> skipping
>>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>>>>>>>> skipping
>>>>>>>>> [INFO] [INFO] Preparing source:jar
>>>>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>>>>>> recursive invocation.
>>>>>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>>>>>> classpath-capable package
>>>>>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>>>>>
>>>>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>>>>>
>>>>>>>>> Then stops at the gpg stage. I thought it would prompt me for my key
>>>>>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>>>>>
>>>>>>>>> updating the parent version wherever it is used (all subproject
>>>>>>>>>> parents)
>>>>>>>>>>
>>>>>>>>>> releasing the subprojects in an appropriate order and updating
>>>>>>>>>> their
>>>>>>>>>> versions wherever they are used.
>>>>>>>>>>
>>>>>>>>>> It might be worthwhile changing the pom version to
>>>>>>>>>> 0.1-incubating-SNAPSHOT
>>>>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this
>>>>>>>>>> because
>>>>>>>>>> then the versions plugin can be used to update use of a subproject
>>>>>>>>>> to
>>>>>>>>>> the
>>>>>>>>>> newly released version of what it uses. Going from
>>>>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>>>>>
>>>>>>>>>> As noted in the "root" pom, don't try to release the root pom and
>>>>>>>>>> don't try
>>>>>>>>>> release everything at once from the root pom.
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>>>>>
>>>>>>>>>> I started looking into cleaning up the build, and of course it is
>>>>>>>>>>> taking
>>>>>>>>>>> longer than I expected.
>>>>>>>>>>>
>>>>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>>>>>
>>>>>>>>>>> There are some projects in application that stop compiling if you
>>>>>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are
>>>>>>>>>>> getting on
>>>>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions
>>>>>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>> dependencies seems to fix it if you can figure out where the out
>>>>>>>>>>> of
>>>>>>>>>>> date
>>>>>>>>>>> jars are coming from.
>>>>>>>>>>>
>>>>>>>>>>> The build is already much closer to a multi-release model than a
>>>>>>>>>>> single
>>>>>>>>>>> release model.
>>>>>>>>>>>
>>>>>>>>>>> I've diffed what I have so far and attached it to ARIES-173. It
>>>>>>>>>>> includes
>>>>>>>>>>> scm info and a lot of version corrections. Due to the failing
>>>>>>>>>>> tests
>>>>>>>>>>> I'm not
>>>>>>>>>>> too comfortable committing it.
>>>>>>>>>>>
>>>>>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi David,
>>>>>>>>>>>> It 'd be great if you are willing to fix these build issues,
>>>>>>>>>>>> since
>>>>>>>>>>>> you
>>>>>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>>>>>
>>>>>>>>>>>> I know the maven release plugin isn't friendly to use some cases,
>>>>>>>>>>>> so
>>>>>>>>>>>> it is best we get these resolved to make our release process a
>>>>>>>>>>>> bit
>>>>>>>>>>>> easier.
>>>>>>>>>>>>
>>>>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time with
>>>>>>>>>>>> the
>>>>>>>>>>>> release.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>> Lin
>>>>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>>>>>> <da...@yahoo.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I would like to understand the problems you see better, but I do
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>>>>>>> explain
>>>>>>>>>>>>>> what
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> problems are, why they are problems and the solution at some
>>>>>>>>>>>>>> point?
>>>>>>>>>>>>>>
>>>>>>>>>>>>> The biggest immediate problem is that without correct svn info
>>>>>>>>>>>>> you
>>>>>>>>>>>>> can't
>>>>>>>>>>>>> do
>>>>>>>>>>>>> a release with the release plugin. I'm pretty sure the way its
>>>>>>>>>>>>> set up
>>>>>>>>>>>>> now,
>>>>>>>>>>>>> when you try, the tag will be under maven's apache pom, not
>>>>>>>>>>>>> aries.
>>>>>>>>>>>>> (you'll
>>>>>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>>>>>> definitely
>>>>>>>>>>>>> don't
>>>>>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>>>>>> application,
>>>>>>>>>>>>> and samples should always be released in synchrony. Any time
>>>>>>>>>>>>> two
>>>>>>>>>>>>> of
>>>>>>>>>>>>> them
>>>>>>>>>>>>> happen to be ready for release at the same time it will be
>>>>>>>>>>>>> purely
>>>>>>>>>>>>> accidental. Right now everyone wants to get a milestone out the
>>>>>>>>>>>>> door,
>>>>>>>>>>>>> but
>>>>>>>>>>>>> looking at the different projects their state of completion is
>>>>>>>>>>>>> pretty
>>>>>>>>>>>>> much
>>>>>>>>>>>>> wildly different. A decision to release all of them at once is
>>>>>>>>>>>>> not
>>>>>>>>>>>>> based in
>>>>>>>>>>>>> any way on them being equally complete. I'm suggesting that
>>>>>>>>>>>>> since
>>>>>>>>>>>>> build
>>>>>>>>>>>>> fixes are needed anyway, why not set up a maintainable structure
>>>>>>>>>>>>> that
>>>>>>>>>>>>> will
>>>>>>>>>>>>> continue to work beyond this publicity release. The benefit to
>>>>>>>>>>>>> users is
>>>>>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>>>>>> otherwise
>>>>>>>>>>>>> the
>>>>>>>>>>>>> entire project will never be in a releasable state at once. (I'm
>>>>>>>>>>>>> only
>>>>>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>>>>>> gyrations that
>>>>>>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>>>>>>> artifact)
>>>>>>>>>>>>> out
>>>>>>>>>>>>> the
>>>>>>>>>>>>> door. This might be ok for one release but (a) I think this can
>>>>>>>>>>>>> be done
>>>>>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>>>>>> eba-maven-plugin
>>>>>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm willing to fix the build and probably work on an eba plugin,
>>>>>>>>>>>>> but
>>>>>>>>>>>>> want to
>>>>>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>> Alasdair
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <david_jencks@yahoo.com
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This discussion got me worried enough to take a look at the
>>>>>>>>>>>>>>> aries
>>>>>>>>>>>>>>> build.
>>>>>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> While it might feel good to try to push out a release as fast
>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>> possible
>>>>>>>>>>>>>>> I'd prefer to see a sustainable build system in place first.
>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>> far
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>>>>>> coupled
>>>>>>>>>>>>>>> subprojects. Building them all at once is not going to work
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> long.
>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>>> To me
>>>>>>>>>>>>>>> this means:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>>>>>>>>> released
>>>>>>>>>>>>>>> (mostly
>>>>>>>>>>>>>>> svn info) (right now this is completely missing everywhere as
>>>>>>>>>>>>>>> far as
>>>>>>>>>>>>>>> I can
>>>>>>>>>>>>>>> see, which will result in ares getting tagged into svn as part
>>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>>> apache
>>>>>>>>>>>>>>> pom)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We can still have a "fake" pom that builds everything, but it
>>>>>>>>>>>>>>> won't be
>>>>>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Having separately released subprojects does not prevent having
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> single
>>>>>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>>>>>>>>> filtered-resources to distinguish when filtering is called
>>>>>>>>>>>>>>> for.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In addition relevant to this particular bit of the thread, we
>>>>>>>>>>>>>>> need an
>>>>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> If there's general agreement I can spend some time playing
>>>>>>>>>>>>>>> with
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> build
>>>>>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thoughts?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'd also like to see us release the sample applications but
>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and
>>>>>>>>>>>>>>>>>> AriesTrader
>>>>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly
>>>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>>>>> being pushed into my local repo. I've made some changes to
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> .eba
>>>>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the
>>>>>>>>>>>>>>>>> .eba for
>>>>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you
>>>>>>>>>>>>>>>> know if
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>>>>> when we do
>>>>>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>>>>>> mechanism for
>>>>>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think the result is that the eba will not be available in
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> One of the differences is that AriesTrader first generates
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> jar
>>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The
>>>>>>>>>>>>>>>>>> jar will
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from
>>>>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work
>>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>>> - is
>>>>>>>>>>>>>>>> there anything wrong with the approach I mentioned earlier of
>>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>>> using the
>>>>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the
>>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>>> application
>>>>>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>>>>>> The transaction component is functional and we've been
>>>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <
>>>>>>>>>>>>>>>>>>> joebohn@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I was really just interested in the general objectives
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> timing
>>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>>>>>>>> little
>>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>>>>> and planning along the same lines (or understand quickly
>>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking
>>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in or
>>>>>>>>>>>>>>>>>>>> out -
>>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> general it doesn't make sense to release things that
>>>>>>>>>>>>>>>>>>>> aren't
>>>>>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect
>>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am
>>>>>>>>>>>>>>>>>>>>> now out
>>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So
>>>>>>>>>>>>>>>>>>>>> 'must
>>>>>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main
>>>>>>>>>>>>>>>>>>>>> area of
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>>>>>>> unknowns
>>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in feb.
>>>>>>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to
>>>>>>>>>>>>>>>>>>>>> 0.1 and
>>>>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>>>>>>>>>>>>> target a
>>>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated
>>>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we
>>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>>>>>>>>> dates
>>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any
>>>>>>>>>>>>>>>>>>>>>>>> help.
>>>>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>>>>>>> interesting
>>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and
>>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as
>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release
>>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see
>>>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>>>
>>>> --
>>>> Joe
>>>>
>>>>
>> --
>> Joe
>>
>
>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Guillaume Nodet <gn...@gmail.com>.
FWIW, I've added to the latest maven bundle plugin a goal that can be used
to transform a string into a correct osgi version.
The goal is now run automatically in the aries build and you can use the
aries.osgi.version.clean property to obtain the correct syntax corresponding
to the maven version.
On Wed, Mar 3, 2010 at 18:48, Joe Bohn <jo...@gmail.com> wrote:
> Sorry, I thought I replied to this yesterday but see that I didn't.
>
>
> Jeremy Hughes wrote:
>
>> On 2 March 2010 19:30, Joe Bohn <jo...@gmail.com> wrote:
>>
>>> Thanks David.
>>>
>>> After I sent my last note I recalled another place in AriesTrader with
>>> hard-coded versions. The APPLICATION.MF files used for the two EBAs
>>> that
>>> are generated includes the bundle version - which is a little different
>>> than
>>> the maven version. Where the maven version is currently
>>> 1.0.0-incubating-SNAPSHOT the bundle version generated using the
>>> maven-bundle-plugin is 1.0.0.incubating-SNAPSHOT to conform to the OSGi
>>> version scheme.
>>>
>>
>> Are you saying we couldn't quite generate the APPLICATION.MF using
>> resource filtering because the ${version} will be
>> 1.0.0-incubating-SNAPSHOT instead of 1.0.0.incubating-SNAPSHOT?
>>
>
> Not necessarily. It's just that we'll need to keep the different format in
> mind.
>
>
>
>> There are two things which might make this a moot point:
>>> 1) If the eba-maven-plugin is enhanced to generate the APPLICATION.MF
>>> then
>>> we can use that to resolve the issue.
>>>
>>
>> Yes I agree eba-maven-plugin should pull the same trick as the
>> maven-bundle-plugin to ensure version numbers fit with the OSGi spec
>> (whatever the logic for that conversion is).
>>
>
> Yes.
>
>
>
>> 2) Even though this is an issue with SNAPSHOTs I imagine it isn't an
>>> issue
>>> with a non-snapshot release because it won't container the "-XXX"
>>> qualification.
>>>
>>
>> I think it'll continue to be an issue while we are using the -incubating
>> suffix.
>>
>
> Agreed. I wasn't sure if we were releasing 0.1 or 0.1-incubating.
>
>
>
>> Optionally, I could also just omit the APPLICATION.MF altogether from the
>>> AriesTrader EBAs since I understand that it is not required. That might
>>> be
>>> quickest fix for now.
>>>
>>
>> Do all the AriesTrader .eba files contain, by value, all the bundles
>> they need? And, is that set transitively closed? If so then you
>> certainly could remove the APPLICATION.MF. Or is it using the OBR
>> resolver integration code to pull in bundles from a repository?
>>
>
> At the moment the eba includes the complete set of bundles by value.
> However, I'm not sure if that will always be the case (or even if it will be
> the case in all environments for some of the dependencies, such as slf4j).
> I'll experiment a bit.
>
>
>
>> Joe
>>>
>>> David Jencks wrote:
>>>
>>>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>>>>
>>>> I agree that we should make a global change to 0.1-incubating-SNAPSHOT
>>>>> first. Why wouldn't we just do that now?
>>>>>
>>>> I started doing some experiments here...
>>>>
>>>> running
>>>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>>>>
>>>> in root and parent upgrades everything maven knows about just fine.
>>>> However there's (1) mentioned below and also a hardcoded version in two
>>>> blueprint-itests.
>>>>
>>>> According to
>>>>
>>>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>>>>
>>>> we should be able to replace the hardcoded versions with
>>>> .versionAsInProject()
>>>>
>>>> if we run the maven-paxexam-plugin on the project. However I can't get
>>>> it
>>>> to work yet.
>>>>
>>>>> Just a heads-up on some other issues related to versions in samples.
>>>>> There are two potential problems that I am aware of:
>>>>>
>>>>> 1) For both Blog-Sample and AriesTrader there are hard-coded version
>>>>> references in the Equinox assembly config.ini file which are used to
>>>>> specify
>>>>> the bundle jars that are to be started for the assembly. Naturally, the
>>>>> versions of the aries bundles in this file won't be updated by the
>>>>> maven-release-plugin. I'm not sure of a good solution for this beyond
>>>>> just
>>>>> manually changing the config.ini files prior to creating a release
>>>>> candidate.
>>>>>
>>>> I think we might be able to work around this by putting the config.ini
>>>> files in src/main/resources/filtered-resources and defining a bunch of
>>>> properties in an appropriate pom and using them for the version imports
>>>> of
>>>> the aries subproject dependencyManagement imports in the samples root
>>>> pom.
>>>> I haven't tried this yet...
>>>>
>>>> 2) I think there is still an unresolved issue related to Blog-Sample
>>>>> and
>>>>> how we might be able to demonstrate a bundle upgrade scenario. I'm
>>>>> not
>>>>> sure if this capability is included yet in Blog-Sample - so it might
>>>>> still
>>>>> be a non-issue at the moment. However, we had some discussion on this
>>>>> a
>>>>> week ago or so related to how we might be able to include multiple
>>>>> versions
>>>>> of components in the sample so that an upgrade scenario could be
>>>>> demonstrated. If that is still a goal for the 0.1 release we will need
>>>>> to
>>>>> come up with some solution.
>>>>>
>>>> no ideas from me on this one :-)
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> Joe
>>>>>
>>>>>
>>>>> David Jencks wrote:
>>>>>
>>>>>> I think everything is ok.... I think (at least with dryRun=true) that
>>>>>> the release plugin builds the project first as-is and checks that
>>>>>> signing
>>>>>> etc works.
>>>>>> I added autoVersionSubmodules=true in the root parent pom which will
>>>>>> make things work more smoothly :-)
>>>>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>>>>>> first, I'm happy to do this if you want.
>>>>>> thanks
>>>>>> david jencks
>>>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>>>
>>>>>>> scratch that. I'm working thru this:
>>>>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>>>>> there's several steps I haven't done.
>>>>>>>
>>>>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>>>
>>>>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>>>>>
>>>>>>>>> I've done most of what I think is needed for aries to be basically
>>>>>>>>> releasable. There are some bits left and possibly stuff I've
>>>>>>>>> missed.
>>>>>>>>>
>>>>>>>>> 1. legal file review. There are a bunch of NOTICE files that claim
>>>>>>>>> that
>>>>>>>>> work from osgi is included. Really? license and notice files are
>>>>>>>>> supposed
>>>>>>>>> to apply to what is actually in an artifact or checkout. Are some
>>>>>>>>> of
>>>>>>>>> our
>>>>>>>>> source files copied from an osgi source? Also all the legal files
>>>>>>>>> that end
>>>>>>>>> up in binary artifacts need to be checked. Also we need to run the
>>>>>>>>> rat
>>>>>>>>> plugin: this should be configured in the default pom. Not sure if
>>>>>>>>> I
>>>>>>>>> will
>>>>>>>>> get to this.
>>>>>>>>>
>>>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how
>>>>>>>>> to
>>>>>>>>> make
>>>>>>>>> sure that an eba is working so I didn't mess with this. I think
>>>>>>>>> the
>>>>>>>>> plugin
>>>>>>>>> itself is working well enough to use though.
>>>>>>>>>
>>>>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>>>>> convenient to
>>>>>>>>> have these alphabetized so I can find what I'm looking for, but I
>>>>>>>>> haven't
>>>>>>>>> done this in most poms. I'm not sure why there isn't a usable tool
>>>>>>>>> for
>>>>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>>>>
>>>>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>>>>> dependency:analyze and
>>>>>>>>> look carefully at the results. The results from this can require
>>>>>>>>> interpretation so its best if someone who is very familiar with how
>>>>>>>>> the code
>>>>>>>>> works does this.
>>>>>>>>>
>>>>>>>>> 4. before a release all snapshots need to be resolved to released
>>>>>>>>> versions.
>>>>>>>>> I don't know if there are any snapshots.
>>>>>>>>>
>>>>>>>>> To summarize what I've tried to do:
>>>>>>>>>
>>>>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>>>>> dependencies
>>>>>>>>> that all projects are pretty sure to use including the pax stuff
>>>>>>>>> used
>>>>>>>>> mostly
>>>>>>>>> for testing.
>>>>>>>>>
>>>>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>>>>
>>>>>>>>> 3. each subproject has an scm element in its pom, but no others do.
>>>>>>>>>
>>>>>>>>> 4. each subproject has dependency management for everything
>>>>>>>>> included
>>>>>>>>> in it.
>>>>>>>>> In addition, it has its subprojects listed in dependency
>>>>>>>>> management.
>>>>>>>>> (this
>>>>>>>>> is bent slightly for the samples). This means that
>>>>>>>>> (a) modules in a subproject don't need to include versions for use
>>>>>>>>> of
>>>>>>>>> other
>>>>>>>>> modules
>>>>>>>>> (b) you can get dependency management for all the modules in a
>>>>>>>>> subproject
>>>>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>>>>> samples pom
>>>>>>>>> for an example).
>>>>>>>>>
>>>>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>>>>> dependency
>>>>>>>>> elements.
>>>>>>>>>
>>>>>>>>> Release is going to involve...
>>>>>>>>>
>>>>>>>>> releasing the parent
>>>>>>>>>
>>>>>>>> In trunk/parent I tried:
>>>>>>>>
>>>>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>>>>
>>>>>>>> Providing 0.1-incubating for the release version
>>>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development
>>>>>>>> version
>>>>>>>>
>>>>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>>>>
>>>>>>>> [INFO] [INFO]
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>>>>> [INFO] [INFO]
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------
>>>>>>>> [INFO] [INFO] [clean:clean]
>>>>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>>>>> 'false'.
>>>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>>>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>>> skipping
>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>>> added,
>>>>>>>> skipping
>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>>>>>>> skipping
>>>>>>>> [INFO] [INFO] Building zip:
>>>>>>>>
>>>>>>>>
>>>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>>> skipping
>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>>> added,
>>>>>>>> skipping
>>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>>>>>>> skipping
>>>>>>>> [INFO] [INFO] Preparing source:jar
>>>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>>>>> recursive invocation.
>>>>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>>>>> classpath-capable package
>>>>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>>>>
>>>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>>>>
>>>>>>>> Then stops at the gpg stage. I thought it would prompt me for my key
>>>>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>>>>
>>>>>>>> updating the parent version wherever it is used (all subproject
>>>>>>>>> parents)
>>>>>>>>>
>>>>>>>>> releasing the subprojects in an appropriate order and updating
>>>>>>>>> their
>>>>>>>>> versions wherever they are used.
>>>>>>>>>
>>>>>>>>> It might be worthwhile changing the pom version to
>>>>>>>>> 0.1-incubating-SNAPSHOT
>>>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this
>>>>>>>>> because
>>>>>>>>> then the versions plugin can be used to update use of a subproject
>>>>>>>>> to
>>>>>>>>> the
>>>>>>>>> newly released version of what it uses. Going from
>>>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>>>>
>>>>>>>>> As noted in the "root" pom, don't try to release the root pom and
>>>>>>>>> don't try
>>>>>>>>> release everything at once from the root pom.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>>>>
>>>>>>>>> I started looking into cleaning up the build, and of course it is
>>>>>>>>>> taking
>>>>>>>>>> longer than I expected.
>>>>>>>>>>
>>>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>>>>
>>>>>>>>>> There are some projects in application that stop compiling if you
>>>>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are
>>>>>>>>>> getting on
>>>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions
>>>>>>>>>> to
>>>>>>>>>> the
>>>>>>>>>> dependencies seems to fix it if you can figure out where the out
>>>>>>>>>> of
>>>>>>>>>> date
>>>>>>>>>> jars are coming from.
>>>>>>>>>>
>>>>>>>>>> The build is already much closer to a multi-release model than a
>>>>>>>>>> single
>>>>>>>>>> release model.
>>>>>>>>>>
>>>>>>>>>> I've diffed what I have so far and attached it to ARIES-173. It
>>>>>>>>>> includes
>>>>>>>>>> scm info and a lot of version corrections. Due to the failing
>>>>>>>>>> tests
>>>>>>>>>> I'm not
>>>>>>>>>> too comfortable committing it.
>>>>>>>>>>
>>>>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>>
>>>>>>>>>>> It 'd be great if you are willing to fix these build issues,
>>>>>>>>>>> since
>>>>>>>>>>> you
>>>>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>>>>
>>>>>>>>>>> I know the maven release plugin isn't friendly to use some cases,
>>>>>>>>>>> so
>>>>>>>>>>> it is best we get these resolved to make our release process a
>>>>>>>>>>> bit
>>>>>>>>>>> easier.
>>>>>>>>>>>
>>>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time with
>>>>>>>>>>> the
>>>>>>>>>>> release.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> Lin
>>>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>>>>> <da...@yahoo.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I would like to understand the problems you see better, but I do
>>>>>>>>>>>>> not
>>>>>>>>>>>>> have
>>>>>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>>>>>> explain
>>>>>>>>>>>>> what
>>>>>>>>>>>>> the
>>>>>>>>>>>>> problems are, why they are problems and the solution at some
>>>>>>>>>>>>> point?
>>>>>>>>>>>>>
>>>>>>>>>>>> The biggest immediate problem is that without correct svn info
>>>>>>>>>>>> you
>>>>>>>>>>>> can't
>>>>>>>>>>>> do
>>>>>>>>>>>> a release with the release plugin. I'm pretty sure the way its
>>>>>>>>>>>> set up
>>>>>>>>>>>> now,
>>>>>>>>>>>> when you try, the tag will be under maven's apache pom, not
>>>>>>>>>>>> aries.
>>>>>>>>>>>> (you'll
>>>>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>>>>> definitely
>>>>>>>>>>>> don't
>>>>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>>>>
>>>>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>>>>> application,
>>>>>>>>>>>> and samples should always be released in synchrony. Any time
>>>>>>>>>>>> two
>>>>>>>>>>>> of
>>>>>>>>>>>> them
>>>>>>>>>>>> happen to be ready for release at the same time it will be
>>>>>>>>>>>> purely
>>>>>>>>>>>> accidental. Right now everyone wants to get a milestone out the
>>>>>>>>>>>> door,
>>>>>>>>>>>> but
>>>>>>>>>>>> looking at the different projects their state of completion is
>>>>>>>>>>>> pretty
>>>>>>>>>>>> much
>>>>>>>>>>>> wildly different. A decision to release all of them at once is
>>>>>>>>>>>> not
>>>>>>>>>>>> based in
>>>>>>>>>>>> any way on them being equally complete. I'm suggesting that
>>>>>>>>>>>> since
>>>>>>>>>>>> build
>>>>>>>>>>>> fixes are needed anyway, why not set up a maintainable structure
>>>>>>>>>>>> that
>>>>>>>>>>>> will
>>>>>>>>>>>> continue to work beyond this publicity release. The benefit to
>>>>>>>>>>>> users is
>>>>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>>>>> otherwise
>>>>>>>>>>>> the
>>>>>>>>>>>> entire project will never be in a releasable state at once. (I'm
>>>>>>>>>>>> only
>>>>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>>>>
>>>>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>>>>> gyrations that
>>>>>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>>>>>> artifact)
>>>>>>>>>>>> out
>>>>>>>>>>>> the
>>>>>>>>>>>> door. This might be ok for one release but (a) I think this can
>>>>>>>>>>>> be done
>>>>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>>>>> eba-maven-plugin
>>>>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>>>>
>>>>>>>>>>>> I'm willing to fix the build and probably work on an eba plugin,
>>>>>>>>>>>> but
>>>>>>>>>>>> want to
>>>>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>>>>
>>>>>>>>>>>> thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>>> Alasdair
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <david_jencks@yahoo.com
>>>>>>>>>>>>> >
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> This discussion got me worried enough to take a look at the
>>>>>>>>>>>>>> aries
>>>>>>>>>>>>>> build.
>>>>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> While it might feel good to try to push out a release as fast
>>>>>>>>>>>>>> as
>>>>>>>>>>>>>> possible
>>>>>>>>>>>>>> I'd prefer to see a sustainable build system in place first.
>>>>>>>>>>>>>> So
>>>>>>>>>>>>>> far
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>>>>> coupled
>>>>>>>>>>>>>> subprojects. Building them all at once is not going to work
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> long.
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>>>>>> system
>>>>>>>>>>>>>> now.
>>>>>>>>>>>>>> To me
>>>>>>>>>>>>>> this means:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>>>>>>>> released
>>>>>>>>>>>>>> (mostly
>>>>>>>>>>>>>> svn info) (right now this is completely missing everywhere as
>>>>>>>>>>>>>> far as
>>>>>>>>>>>>>> I can
>>>>>>>>>>>>>> see, which will result in ares getting tagged into svn as part
>>>>>>>>>>>>>> of the
>>>>>>>>>>>>>> apache
>>>>>>>>>>>>>> pom)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We can still have a "fake" pom that builds everything, but it
>>>>>>>>>>>>>> won't be
>>>>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Having separately released subprojects does not prevent having
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> single
>>>>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>>>>>>>> filtered-resources to distinguish when filtering is called
>>>>>>>>>>>>>> for.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> In addition relevant to this particular bit of the thread, we
>>>>>>>>>>>>>> need an
>>>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>>>>>>>>>>> release
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> If there's general agreement I can spend some time playing
>>>>>>>>>>>>>> with
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> build
>>>>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thoughts?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> thanks
>>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'd also like to see us release the sample applications but
>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and
>>>>>>>>>>>>>>>>> AriesTrader
>>>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly
>>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>>>> being pushed into my local repo. I've made some changes to
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> .eba
>>>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the
>>>>>>>>>>>>>>>> .eba for
>>>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you
>>>>>>>>>>>>>>> know if
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>>>> when we do
>>>>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>>>>> mechanism for
>>>>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think the result is that the eba will not be available in
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> One of the differences is that AriesTrader first generates
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> jar
>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The
>>>>>>>>>>>>>>>>> jar will
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from
>>>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work
>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>> - is
>>>>>>>>>>>>>>> there anything wrong with the approach I mentioned earlier of
>>>>>>>>>>>>>>> just
>>>>>>>>>>>>>>> using the
>>>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the
>>>>>>>>>>>>>>> current
>>>>>>>>>>>>>>> application
>>>>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>>>>> The transaction component is functional and we've been
>>>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <
>>>>>>>>>>>>>>>>>> joebohn@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I was really just interested in the general objectives
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> timing
>>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>>>>>>> little
>>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>>>> and planning along the same lines (or understand quickly
>>>>>>>>>>>>>>>>>>> if
>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking
>>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in or
>>>>>>>>>>>>>>>>>>> out -
>>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> general it doesn't make sense to release things that
>>>>>>>>>>>>>>>>>>> aren't
>>>>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect
>>>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am
>>>>>>>>>>>>>>>>>>>> now out
>>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So
>>>>>>>>>>>>>>>>>>>> 'must
>>>>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main
>>>>>>>>>>>>>>>>>>>> area of
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>>>>>> unknowns
>>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in feb.
>>>>>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to
>>>>>>>>>>>>>>>>>>>> 0.1 and
>>>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>>>>>>>>>>>> target a
>>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated
>>>>>>>>>>>>>>>>>>>>> as
>>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we
>>>>>>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>>>>>>>> dates
>>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any
>>>>>>>>>>>>>>>>>>>>>>> help.
>>>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>>>>>> interesting
>>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and
>>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as
>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release
>>>>>>>>>>>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see
>>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>>
>>>>
>>> --
>>> Joe
>>>
>>>
>>
>
> --
> Joe
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
Sorry, I thought I replied to this yesterday but see that I didn't.
Jeremy Hughes wrote:
> On 2 March 2010 19:30, Joe Bohn <jo...@gmail.com> wrote:
>> Thanks David.
>>
>> After I sent my last note I recalled another place in AriesTrader with
>> hard-coded versions. The APPLICATION.MF files used for the two EBAs that
>> are generated includes the bundle version - which is a little different than
>> the maven version. Where the maven version is currently
>> 1.0.0-incubating-SNAPSHOT the bundle version generated using the
>> maven-bundle-plugin is 1.0.0.incubating-SNAPSHOT to conform to the OSGi
>> version scheme.
>
> Are you saying we couldn't quite generate the APPLICATION.MF using
> resource filtering because the ${version} will be
> 1.0.0-incubating-SNAPSHOT instead of 1.0.0.incubating-SNAPSHOT?
Not necessarily. It's just that we'll need to keep the different format
in mind.
>
>> There are two things which might make this a moot point:
>> 1) If the eba-maven-plugin is enhanced to generate the APPLICATION.MF then
>> we can use that to resolve the issue.
>
> Yes I agree eba-maven-plugin should pull the same trick as the
> maven-bundle-plugin to ensure version numbers fit with the OSGi spec
> (whatever the logic for that conversion is).
Yes.
>
>> 2) Even though this is an issue with SNAPSHOTs I imagine it isn't an issue
>> with a non-snapshot release because it won't container the "-XXX"
>> qualification.
>
> I think it'll continue to be an issue while we are using the -incubating suffix.
Agreed. I wasn't sure if we were releasing 0.1 or 0.1-incubating.
>
>> Optionally, I could also just omit the APPLICATION.MF altogether from the
>> AriesTrader EBAs since I understand that it is not required. That might be
>> quickest fix for now.
>
> Do all the AriesTrader .eba files contain, by value, all the bundles
> they need? And, is that set transitively closed? If so then you
> certainly could remove the APPLICATION.MF. Or is it using the OBR
> resolver integration code to pull in bundles from a repository?
At the moment the eba includes the complete set of bundles by value.
However, I'm not sure if that will always be the case (or even if it
will be the case in all environments for some of the dependencies, such
as slf4j). I'll experiment a bit.
>
>> Joe
>>
>> David Jencks wrote:
>>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>>>
>>>> I agree that we should make a global change to 0.1-incubating-SNAPSHOT
>>>> first. Why wouldn't we just do that now?
>>> I started doing some experiments here...
>>>
>>> running
>>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>>>
>>> in root and parent upgrades everything maven knows about just fine.
>>> However there's (1) mentioned below and also a hardcoded version in two
>>> blueprint-itests.
>>>
>>> According to
>>>
>>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>>>
>>> we should be able to replace the hardcoded versions with
>>> .versionAsInProject()
>>>
>>> if we run the maven-paxexam-plugin on the project. However I can't get it
>>> to work yet.
>>>> Just a heads-up on some other issues related to versions in samples.
>>>> There are two potential problems that I am aware of:
>>>>
>>>> 1) For both Blog-Sample and AriesTrader there are hard-coded version
>>>> references in the Equinox assembly config.ini file which are used to specify
>>>> the bundle jars that are to be started for the assembly. Naturally, the
>>>> versions of the aries bundles in this file won't be updated by the
>>>> maven-release-plugin. I'm not sure of a good solution for this beyond just
>>>> manually changing the config.ini files prior to creating a release
>>>> candidate.
>>> I think we might be able to work around this by putting the config.ini
>>> files in src/main/resources/filtered-resources and defining a bunch of
>>> properties in an appropriate pom and using them for the version imports of
>>> the aries subproject dependencyManagement imports in the samples root pom.
>>> I haven't tried this yet...
>>>
>>>> 2) I think there is still an unresolved issue related to Blog-Sample and
>>>> how we might be able to demonstrate a bundle upgrade scenario. I'm not
>>>> sure if this capability is included yet in Blog-Sample - so it might still
>>>> be a non-issue at the moment. However, we had some discussion on this a
>>>> week ago or so related to how we might be able to include multiple versions
>>>> of components in the sample so that an upgrade scenario could be
>>>> demonstrated. If that is still a goal for the 0.1 release we will need to
>>>> come up with some solution.
>>> no ideas from me on this one :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>> Joe
>>>>
>>>>
>>>> David Jencks wrote:
>>>>> I think everything is ok.... I think (at least with dryRun=true) that
>>>>> the release plugin builds the project first as-is and checks that signing
>>>>> etc works.
>>>>> I added autoVersionSubmodules=true in the root parent pom which will
>>>>> make things work more smoothly :-)
>>>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>>>>> first, I'm happy to do this if you want.
>>>>> thanks
>>>>> david jencks
>>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>>> scratch that. I'm working thru this:
>>>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>>>> there's several steps I haven't done.
>>>>>>
>>>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>>>>> I've done most of what I think is needed for aries to be basically
>>>>>>>> releasable. There are some bits left and possibly stuff I've missed.
>>>>>>>>
>>>>>>>> 1. legal file review. There are a bunch of NOTICE files that claim
>>>>>>>> that
>>>>>>>> work from osgi is included. Really? license and notice files are
>>>>>>>> supposed
>>>>>>>> to apply to what is actually in an artifact or checkout. Are some of
>>>>>>>> our
>>>>>>>> source files copied from an osgi source? Also all the legal files
>>>>>>>> that end
>>>>>>>> up in binary artifacts need to be checked. Also we need to run the
>>>>>>>> rat
>>>>>>>> plugin: this should be configured in the default pom. Not sure if I
>>>>>>>> will
>>>>>>>> get to this.
>>>>>>>>
>>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how to
>>>>>>>> make
>>>>>>>> sure that an eba is working so I didn't mess with this. I think the
>>>>>>>> plugin
>>>>>>>> itself is working well enough to use though.
>>>>>>>>
>>>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>>>> convenient to
>>>>>>>> have these alphabetized so I can find what I'm looking for, but I
>>>>>>>> haven't
>>>>>>>> done this in most poms. I'm not sure why there isn't a usable tool
>>>>>>>> for
>>>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>>>
>>>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>>>> dependency:analyze and
>>>>>>>> look carefully at the results. The results from this can require
>>>>>>>> interpretation so its best if someone who is very familiar with how
>>>>>>>> the code
>>>>>>>> works does this.
>>>>>>>>
>>>>>>>> 4. before a release all snapshots need to be resolved to released
>>>>>>>> versions.
>>>>>>>> I don't know if there are any snapshots.
>>>>>>>>
>>>>>>>> To summarize what I've tried to do:
>>>>>>>>
>>>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>>>> dependencies
>>>>>>>> that all projects are pretty sure to use including the pax stuff used
>>>>>>>> mostly
>>>>>>>> for testing.
>>>>>>>>
>>>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>>>
>>>>>>>> 3. each subproject has an scm element in its pom, but no others do.
>>>>>>>>
>>>>>>>> 4. each subproject has dependency management for everything included
>>>>>>>> in it.
>>>>>>>> In addition, it has its subprojects listed in dependency management.
>>>>>>>> (this
>>>>>>>> is bent slightly for the samples). This means that
>>>>>>>> (a) modules in a subproject don't need to include versions for use of
>>>>>>>> other
>>>>>>>> modules
>>>>>>>> (b) you can get dependency management for all the modules in a
>>>>>>>> subproject
>>>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>>>> samples pom
>>>>>>>> for an example).
>>>>>>>>
>>>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>>>> dependency
>>>>>>>> elements.
>>>>>>>>
>>>>>>>> Release is going to involve...
>>>>>>>>
>>>>>>>> releasing the parent
>>>>>>> In trunk/parent I tried:
>>>>>>>
>>>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>>>
>>>>>>> Providing 0.1-incubating for the release version
>>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development version
>>>>>>>
>>>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>>>
>>>>>>> [INFO] [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>>>> [INFO] [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>> [INFO] [INFO] [clean:clean]
>>>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>>>> 'false'.
>>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] Building zip:
>>>>>>>
>>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] Preparing source:jar
>>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>>>> recursive invocation.
>>>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>>>> classpath-capable package
>>>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>>>
>>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>>>
>>>>>>> Then stops at the gpg stage. I thought it would prompt me for my key
>>>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>>>
>>>>>>>> updating the parent version wherever it is used (all subproject
>>>>>>>> parents)
>>>>>>>>
>>>>>>>> releasing the subprojects in an appropriate order and updating their
>>>>>>>> versions wherever they are used.
>>>>>>>>
>>>>>>>> It might be worthwhile changing the pom version to
>>>>>>>> 0.1-incubating-SNAPSHOT
>>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this
>>>>>>>> because
>>>>>>>> then the versions plugin can be used to update use of a subproject to
>>>>>>>> the
>>>>>>>> newly released version of what it uses. Going from
>>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>>>
>>>>>>>> As noted in the "root" pom, don't try to release the root pom and
>>>>>>>> don't try
>>>>>>>> release everything at once from the root pom.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> I started looking into cleaning up the build, and of course it is
>>>>>>>>> taking
>>>>>>>>> longer than I expected.
>>>>>>>>>
>>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>>>
>>>>>>>>> There are some projects in application that stop compiling if you
>>>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are
>>>>>>>>> getting on
>>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions to
>>>>>>>>> the
>>>>>>>>> dependencies seems to fix it if you can figure out where the out of
>>>>>>>>> date
>>>>>>>>> jars are coming from.
>>>>>>>>>
>>>>>>>>> The build is already much closer to a multi-release model than a
>>>>>>>>> single
>>>>>>>>> release model.
>>>>>>>>>
>>>>>>>>> I've diffed what I have so far and attached it to ARIES-173. It
>>>>>>>>> includes
>>>>>>>>> scm info and a lot of version corrections. Due to the failing tests
>>>>>>>>> I'm not
>>>>>>>>> too comfortable committing it.
>>>>>>>>>
>>>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> It 'd be great if you are willing to fix these build issues, since
>>>>>>>>>> you
>>>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>>>
>>>>>>>>>> I know the maven release plugin isn't friendly to use some cases,
>>>>>>>>>> so
>>>>>>>>>> it is best we get these resolved to make our release process a bit
>>>>>>>>>> easier.
>>>>>>>>>>
>>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time with
>>>>>>>>>> the
>>>>>>>>>> release.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Lin
>>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>>>> <da...@yahoo.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>> I would like to understand the problems you see better, but I do
>>>>>>>>>>>> not
>>>>>>>>>>>> have
>>>>>>>>>>>> the maven background you guys have, any chance you could explain
>>>>>>>>>>>> what
>>>>>>>>>>>> the
>>>>>>>>>>>> problems are, why they are problems and the solution at some
>>>>>>>>>>>> point?
>>>>>>>>>>> The biggest immediate problem is that without correct svn info you
>>>>>>>>>>> can't
>>>>>>>>>>> do
>>>>>>>>>>> a release with the release plugin. I'm pretty sure the way its
>>>>>>>>>>> set up
>>>>>>>>>>> now,
>>>>>>>>>>> when you try, the tag will be under maven's apache pom, not aries.
>>>>>>>>>>> (you'll
>>>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>>>> definitely
>>>>>>>>>>> don't
>>>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>>>
>>>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>>>> application,
>>>>>>>>>>> and samples should always be released in synchrony. Any time two
>>>>>>>>>>> of
>>>>>>>>>>> them
>>>>>>>>>>> happen to be ready for release at the same time it will be purely
>>>>>>>>>>> accidental. Right now everyone wants to get a milestone out the
>>>>>>>>>>> door,
>>>>>>>>>>> but
>>>>>>>>>>> looking at the different projects their state of completion is
>>>>>>>>>>> pretty
>>>>>>>>>>> much
>>>>>>>>>>> wildly different. A decision to release all of them at once is
>>>>>>>>>>> not
>>>>>>>>>>> based in
>>>>>>>>>>> any way on them being equally complete. I'm suggesting that since
>>>>>>>>>>> build
>>>>>>>>>>> fixes are needed anyway, why not set up a maintainable structure
>>>>>>>>>>> that
>>>>>>>>>>> will
>>>>>>>>>>> continue to work beyond this publicity release. The benefit to
>>>>>>>>>>> users is
>>>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>>>> otherwise
>>>>>>>>>>> the
>>>>>>>>>>> entire project will never be in a releasable state at once. (I'm
>>>>>>>>>>> only
>>>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>>>
>>>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>>>> gyrations that
>>>>>>>>>>> don't really use maven properly to get an .eba (or some artifact)
>>>>>>>>>>> out
>>>>>>>>>>> the
>>>>>>>>>>> door. This might be ok for one release but (a) I think this can
>>>>>>>>>>> be done
>>>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>>>> eba-maven-plugin
>>>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>>>
>>>>>>>>>>> I'm willing to fix the build and probably work on an eba plugin,
>>>>>>>>>>> but
>>>>>>>>>>> want to
>>>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Alasdair
>>>>>>>>>>>>
>>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> This discussion got me worried enough to take a look at the
>>>>>>>>>>>>> aries
>>>>>>>>>>>>> build.
>>>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>>>
>>>>>>>>>>>>> While it might feel good to try to push out a release as fast as
>>>>>>>>>>>>> possible
>>>>>>>>>>>>> I'd prefer to see a sustainable build system in place first. So
>>>>>>>>>>>>> far
>>>>>>>>>>>>> it
>>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>>>> coupled
>>>>>>>>>>>>> subprojects. Building them all at once is not going to work for
>>>>>>>>>>>>> long.
>>>>>>>>>>>>> I
>>>>>>>>>>>>> think we should recognize that and put that in the build system
>>>>>>>>>>>>> now.
>>>>>>>>>>>>> To me
>>>>>>>>>>>>> this means:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>>>>>>>>>> (mostly
>>>>>>>>>>>>> svn info) (right now this is completely missing everywhere as
>>>>>>>>>>>>> far as
>>>>>>>>>>>>> I can
>>>>>>>>>>>>> see, which will result in ares getting tagged into svn as part
>>>>>>>>>>>>> of the
>>>>>>>>>>>>> apache
>>>>>>>>>>>>> pom)
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can still have a "fake" pom that builds everything, but it
>>>>>>>>>>>>> won't be
>>>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Having separately released subprojects does not prevent having a
>>>>>>>>>>>>> single
>>>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>>>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In addition relevant to this particular bit of the thread, we
>>>>>>>>>>>>> need an
>>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>>>>>>>>>> release
>>>>>>>>>>>>> would
>>>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If there's general agreement I can spend some time playing with
>>>>>>>>>>>>> the
>>>>>>>>>>>>> build
>>>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thoughts?
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>> I'd also like to see us release the sample applications but I
>>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the
>>>>>>>>>>>>>>> .eba
>>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the
>>>>>>>>>>>>>>> .eba for
>>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you
>>>>>>>>>>>>>> know if
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>>> when we do
>>>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>>>> mechanism for
>>>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think the result is that the eba will not be available in a
>>>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One of the differences is that AriesTrader first generates a
>>>>>>>>>>>>>>>> jar
>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The
>>>>>>>>>>>>>>>> jar will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred approach
>>>>>>>>>>>>>>> long
>>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from
>>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work out
>>>>>>>>>>>>>> - is
>>>>>>>>>>>>>> there anything wrong with the approach I mentioned earlier of
>>>>>>>>>>>>>> just
>>>>>>>>>>>>>> using the
>>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>>>>>>>>>> application
>>>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>>>> The transaction component is functional and we've been using
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I was really just interested in the general objectives and
>>>>>>>>>>>>>>>>>> timing
>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a little
>>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>>> and planning along the same lines (or understand quickly if
>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> release candidate next week means that we should be getting
>>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in or
>>>>>>>>>>>>>>>>>> out -
>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect not
>>>>>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am
>>>>>>>>>>>>>>>>>>> now out
>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So
>>>>>>>>>>>>>>>>>>> 'must
>>>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main
>>>>>>>>>>>>>>>>>>> area of
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>>> this is the first release there are likely a few unknowns
>>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in feb.
>>>>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to
>>>>>>>>>>>>>>>>>>> 0.1 and
>>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>>>>>>>>>>> target a
>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as
>>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we would
>>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> have"), the current status of that content, target dates
>>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting
>>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and
>>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as
>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is
>>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>
>>>>
>>>> --
>>>> Joe
>>>
>>
>> --
>> Joe
>>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 2 March 2010 19:30, Joe Bohn <jo...@gmail.com> wrote:
> Thanks David.
>
> After I sent my last note I recalled another place in AriesTrader with
> hard-coded versions. The APPLICATION.MF files used for the two EBAs that
> are generated includes the bundle version - which is a little different than
> the maven version. Where the maven version is currently
> 1.0.0-incubating-SNAPSHOT the bundle version generated using the
> maven-bundle-plugin is 1.0.0.incubating-SNAPSHOT to conform to the OSGi
> version scheme.
Are you saying we couldn't quite generate the APPLICATION.MF using
resource filtering because the ${version} will be
1.0.0-incubating-SNAPSHOT instead of 1.0.0.incubating-SNAPSHOT?
>
> There are two things which might make this a moot point:
> 1) If the eba-maven-plugin is enhanced to generate the APPLICATION.MF then
> we can use that to resolve the issue.
Yes I agree eba-maven-plugin should pull the same trick as the
maven-bundle-plugin to ensure version numbers fit with the OSGi spec
(whatever the logic for that conversion is).
> 2) Even though this is an issue with SNAPSHOTs I imagine it isn't an issue
> with a non-snapshot release because it won't container the "-XXX"
> qualification.
I think it'll continue to be an issue while we are using the -incubating suffix.
>
> Optionally, I could also just omit the APPLICATION.MF altogether from the
> AriesTrader EBAs since I understand that it is not required. That might be
> quickest fix for now.
Do all the AriesTrader .eba files contain, by value, all the bundles
they need? And, is that set transitively closed? If so then you
certainly could remove the APPLICATION.MF. Or is it using the OBR
resolver integration code to pull in bundles from a repository?
>
> Joe
>
> David Jencks wrote:
>>
>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>>
>>> I agree that we should make a global change to 0.1-incubating-SNAPSHOT
>>> first. Why wouldn't we just do that now?
>>
>> I started doing some experiments here...
>>
>> running
>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>>
>> in root and parent upgrades everything maven knows about just fine.
>> However there's (1) mentioned below and also a hardcoded version in two
>> blueprint-itests.
>>
>> According to
>>
>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>>
>> we should be able to replace the hardcoded versions with
>> .versionAsInProject()
>>
>> if we run the maven-paxexam-plugin on the project. However I can't get it
>> to work yet.
>>>
>>> Just a heads-up on some other issues related to versions in samples.
>>> There are two potential problems that I am aware of:
>>>
>>> 1) For both Blog-Sample and AriesTrader there are hard-coded version
>>> references in the Equinox assembly config.ini file which are used to specify
>>> the bundle jars that are to be started for the assembly. Naturally, the
>>> versions of the aries bundles in this file won't be updated by the
>>> maven-release-plugin. I'm not sure of a good solution for this beyond just
>>> manually changing the config.ini files prior to creating a release
>>> candidate.
>>
>> I think we might be able to work around this by putting the config.ini
>> files in src/main/resources/filtered-resources and defining a bunch of
>> properties in an appropriate pom and using them for the version imports of
>> the aries subproject dependencyManagement imports in the samples root pom.
>> I haven't tried this yet...
>>
>>>
>>> 2) I think there is still an unresolved issue related to Blog-Sample and
>>> how we might be able to demonstrate a bundle upgrade scenario. I'm not
>>> sure if this capability is included yet in Blog-Sample - so it might still
>>> be a non-issue at the moment. However, we had some discussion on this a
>>> week ago or so related to how we might be able to include multiple versions
>>> of components in the sample so that an upgrade scenario could be
>>> demonstrated. If that is still a goal for the 0.1 release we will need to
>>> come up with some solution.
>>
>> no ideas from me on this one :-)
>>
>> thanks
>> david jencks
>>
>>>
>>> Joe
>>>
>>>
>>> David Jencks wrote:
>>>>
>>>> I think everything is ok.... I think (at least with dryRun=true) that
>>>> the release plugin builds the project first as-is and checks that signing
>>>> etc works.
>>>> I added autoVersionSubmodules=true in the root parent pom which will
>>>> make things work more smoothly :-)
>>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>>>> first, I'm happy to do this if you want.
>>>> thanks
>>>> david jencks
>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>>
>>>>> scratch that. I'm working thru this:
>>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>>> there's several steps I haven't done.
>>>>>
>>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>>
>>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>>>>
>>>>>>> I've done most of what I think is needed for aries to be basically
>>>>>>> releasable. There are some bits left and possibly stuff I've missed.
>>>>>>>
>>>>>>> 1. legal file review. There are a bunch of NOTICE files that claim
>>>>>>> that
>>>>>>> work from osgi is included. Really? license and notice files are
>>>>>>> supposed
>>>>>>> to apply to what is actually in an artifact or checkout. Are some of
>>>>>>> our
>>>>>>> source files copied from an osgi source? Also all the legal files
>>>>>>> that end
>>>>>>> up in binary artifacts need to be checked. Also we need to run the
>>>>>>> rat
>>>>>>> plugin: this should be configured in the default pom. Not sure if I
>>>>>>> will
>>>>>>> get to this.
>>>>>>>
>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how to
>>>>>>> make
>>>>>>> sure that an eba is working so I didn't mess with this. I think the
>>>>>>> plugin
>>>>>>> itself is working well enough to use though.
>>>>>>>
>>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>>> convenient to
>>>>>>> have these alphabetized so I can find what I'm looking for, but I
>>>>>>> haven't
>>>>>>> done this in most poms. I'm not sure why there isn't a usable tool
>>>>>>> for
>>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>>
>>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>>> dependency:analyze and
>>>>>>> look carefully at the results. The results from this can require
>>>>>>> interpretation so its best if someone who is very familiar with how
>>>>>>> the code
>>>>>>> works does this.
>>>>>>>
>>>>>>> 4. before a release all snapshots need to be resolved to released
>>>>>>> versions.
>>>>>>> I don't know if there are any snapshots.
>>>>>>>
>>>>>>> To summarize what I've tried to do:
>>>>>>>
>>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>>> dependencies
>>>>>>> that all projects are pretty sure to use including the pax stuff used
>>>>>>> mostly
>>>>>>> for testing.
>>>>>>>
>>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>>
>>>>>>> 3. each subproject has an scm element in its pom, but no others do.
>>>>>>>
>>>>>>> 4. each subproject has dependency management for everything included
>>>>>>> in it.
>>>>>>> In addition, it has its subprojects listed in dependency management.
>>>>>>> (this
>>>>>>> is bent slightly for the samples). This means that
>>>>>>> (a) modules in a subproject don't need to include versions for use of
>>>>>>> other
>>>>>>> modules
>>>>>>> (b) you can get dependency management for all the modules in a
>>>>>>> subproject
>>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>>> samples pom
>>>>>>> for an example).
>>>>>>>
>>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>>> dependency
>>>>>>> elements.
>>>>>>>
>>>>>>> Release is going to involve...
>>>>>>>
>>>>>>> releasing the parent
>>>>>>
>>>>>> In trunk/parent I tried:
>>>>>>
>>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>>
>>>>>> Providing 0.1-incubating for the release version
>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development version
>>>>>>
>>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>>
>>>>>> [INFO] [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>>> [INFO] [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [INFO] [INFO] [clean:clean]
>>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>>> 'false'.
>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>> skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added,
>>>>>> skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>>>>> skipping
>>>>>> [INFO] [INFO] Building zip:
>>>>>>
>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>> skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added,
>>>>>> skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>>>>> skipping
>>>>>> [INFO] [INFO] Preparing source:jar
>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>>> recursive invocation.
>>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>>> classpath-capable package
>>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>>
>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>>
>>>>>> Then stops at the gpg stage. I thought it would prompt me for my key
>>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>>
>>>>>>> updating the parent version wherever it is used (all subproject
>>>>>>> parents)
>>>>>>>
>>>>>>> releasing the subprojects in an appropriate order and updating their
>>>>>>> versions wherever they are used.
>>>>>>>
>>>>>>> It might be worthwhile changing the pom version to
>>>>>>> 0.1-incubating-SNAPSHOT
>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this
>>>>>>> because
>>>>>>> then the versions plugin can be used to update use of a subproject to
>>>>>>> the
>>>>>>> newly released version of what it uses. Going from
>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>>
>>>>>>> As noted in the "root" pom, don't try to release the root pom and
>>>>>>> don't try
>>>>>>> release everything at once from the root pom.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>>
>>>>>>>> I started looking into cleaning up the build, and of course it is
>>>>>>>> taking
>>>>>>>> longer than I expected.
>>>>>>>>
>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>>
>>>>>>>> There are some projects in application that stop compiling if you
>>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are
>>>>>>>> getting on
>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions to
>>>>>>>> the
>>>>>>>> dependencies seems to fix it if you can figure out where the out of
>>>>>>>> date
>>>>>>>> jars are coming from.
>>>>>>>>
>>>>>>>> The build is already much closer to a multi-release model than a
>>>>>>>> single
>>>>>>>> release model.
>>>>>>>>
>>>>>>>> I've diffed what I have so far and attached it to ARIES-173. It
>>>>>>>> includes
>>>>>>>> scm info and a lot of version corrections. Due to the failing tests
>>>>>>>> I'm not
>>>>>>>> too comfortable committing it.
>>>>>>>>
>>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>>
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> It 'd be great if you are willing to fix these build issues, since
>>>>>>>>> you
>>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>>
>>>>>>>>> I know the maven release plugin isn't friendly to use some cases,
>>>>>>>>> so
>>>>>>>>> it is best we get these resolved to make our release process a bit
>>>>>>>>> easier.
>>>>>>>>>
>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time with
>>>>>>>>> the
>>>>>>>>> release.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Lin
>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>>> <da...@yahoo.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I would like to understand the problems you see better, but I do
>>>>>>>>>>> not
>>>>>>>>>>> have
>>>>>>>>>>> the maven background you guys have, any chance you could explain
>>>>>>>>>>> what
>>>>>>>>>>> the
>>>>>>>>>>> problems are, why they are problems and the solution at some
>>>>>>>>>>> point?
>>>>>>>>>>
>>>>>>>>>> The biggest immediate problem is that without correct svn info you
>>>>>>>>>> can't
>>>>>>>>>> do
>>>>>>>>>> a release with the release plugin. I'm pretty sure the way its
>>>>>>>>>> set up
>>>>>>>>>> now,
>>>>>>>>>> when you try, the tag will be under maven's apache pom, not aries.
>>>>>>>>>> (you'll
>>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>>> definitely
>>>>>>>>>> don't
>>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>>
>>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>>> application,
>>>>>>>>>> and samples should always be released in synchrony. Any time two
>>>>>>>>>> of
>>>>>>>>>> them
>>>>>>>>>> happen to be ready for release at the same time it will be purely
>>>>>>>>>> accidental. Right now everyone wants to get a milestone out the
>>>>>>>>>> door,
>>>>>>>>>> but
>>>>>>>>>> looking at the different projects their state of completion is
>>>>>>>>>> pretty
>>>>>>>>>> much
>>>>>>>>>> wildly different. A decision to release all of them at once is
>>>>>>>>>> not
>>>>>>>>>> based in
>>>>>>>>>> any way on them being equally complete. I'm suggesting that since
>>>>>>>>>> build
>>>>>>>>>> fixes are needed anyway, why not set up a maintainable structure
>>>>>>>>>> that
>>>>>>>>>> will
>>>>>>>>>> continue to work beyond this publicity release. The benefit to
>>>>>>>>>> users is
>>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>>> otherwise
>>>>>>>>>> the
>>>>>>>>>> entire project will never be in a releasable state at once. (I'm
>>>>>>>>>> only
>>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>>
>>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>>> gyrations that
>>>>>>>>>> don't really use maven properly to get an .eba (or some artifact)
>>>>>>>>>> out
>>>>>>>>>> the
>>>>>>>>>> door. This might be ok for one release but (a) I think this can
>>>>>>>>>> be done
>>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>>> eba-maven-plugin
>>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>>
>>>>>>>>>> I'm willing to fix the build and probably work on an eba plugin,
>>>>>>>>>> but
>>>>>>>>>> want to
>>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Alasdair
>>>>>>>>>>>
>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> This discussion got me worried enough to take a look at the
>>>>>>>>>>>> aries
>>>>>>>>>>>> build.
>>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>>
>>>>>>>>>>>> While it might feel good to try to push out a release as fast as
>>>>>>>>>>>> possible
>>>>>>>>>>>> I'd prefer to see a sustainable build system in place first. So
>>>>>>>>>>>> far
>>>>>>>>>>>> it
>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>>> coupled
>>>>>>>>>>>> subprojects. Building them all at once is not going to work for
>>>>>>>>>>>> long.
>>>>>>>>>>>> I
>>>>>>>>>>>> think we should recognize that and put that in the build system
>>>>>>>>>>>> now.
>>>>>>>>>>>> To me
>>>>>>>>>>>> this means:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>>>>>>>>> (mostly
>>>>>>>>>>>> svn info) (right now this is completely missing everywhere as
>>>>>>>>>>>> far as
>>>>>>>>>>>> I can
>>>>>>>>>>>> see, which will result in ares getting tagged into svn as part
>>>>>>>>>>>> of the
>>>>>>>>>>>> apache
>>>>>>>>>>>> pom)
>>>>>>>>>>>>
>>>>>>>>>>>> We can still have a "fake" pom that builds everything, but it
>>>>>>>>>>>> won't be
>>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>>
>>>>>>>>>>>> Having separately released subprojects does not prevent having a
>>>>>>>>>>>> single
>>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>>
>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>>>>>>>>
>>>>>>>>>>>> In addition relevant to this particular bit of the thread, we
>>>>>>>>>>>> need an
>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>>>>>>>>> release
>>>>>>>>>>>> would
>>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>>
>>>>>>>>>>>> If there's general agreement I can spend some time playing with
>>>>>>>>>>>> the
>>>>>>>>>>>> build
>>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>>
>>>>>>>>>>>> thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>> thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd also like to see us release the sample applications but I
>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the
>>>>>>>>>>>>>> .eba
>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the
>>>>>>>>>>>>>> .eba for
>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you
>>>>>>>>>>>>> know if
>>>>>>>>>>>>> it
>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>> when we do
>>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>>> mechanism for
>>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think the result is that the eba will not be available in a
>>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> One of the differences is that AriesTrader first generates a
>>>>>>>>>>>>>>> jar
>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The
>>>>>>>>>>>>>>> jar will
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred approach
>>>>>>>>>>>>>> long
>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from
>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work out
>>>>>>>>>>>>> - is
>>>>>>>>>>>>> there anything wrong with the approach I mentioned earlier of
>>>>>>>>>>>>> just
>>>>>>>>>>>>> using the
>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>>>>>>>>> application
>>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>>> The transaction component is functional and we've been using
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I was really just interested in the general objectives and
>>>>>>>>>>>>>>>>> timing
>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a little
>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>> and planning along the same lines (or understand quickly if
>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> release candidate next week means that we should be getting
>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in or
>>>>>>>>>>>>>>>>> out -
>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect not
>>>>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am
>>>>>>>>>>>>>>>>>> now out
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So
>>>>>>>>>>>>>>>>>> 'must
>>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main
>>>>>>>>>>>>>>>>>> area of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>> this is the first release there are likely a few unknowns
>>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in feb.
>>>>>>>>>>>>>>>>>> If
>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to
>>>>>>>>>>>>>>>>>> 0.1 and
>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>>>>>>>>>> target a
>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as
>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we would
>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> have"), the current status of that content, target dates
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as
>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is
>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>>
>>> --
>>> Joe
>>
>>
>
>
> --
> Joe
>
Re: [DISCUSSION] Aries release
Posted by Lin Sun <li...@gmail.com>.
Hi
I normally would get failed at one of the blueprint itest but today I
was able to get a successful build.
I agree with you that the projects are much closer to a multi-release model.
I tried your patch and I started to see all itests in application got
errors. The error came from pax exam during setup so the tests
didn't get executed.
Lin
On Thu, Feb 25, 2010 at 2:55 AM, David Jencks <da...@yahoo.com> wrote:
> I started looking into cleaning up the build, and of course it is taking
> longer than I expected.
>
> I'm seriously hampered by failing tests in a fresh checkout.
>
> There are some projects in application that stop compiling if you
> alphabetize the dependencies. It looks like osgi 3 artifacts are getting on
> the maven classpath before osgi 4.2 artifacts. Adding exclusions to the
> dependencies seems to fix it if you can figure out where the out of date
> jars are coming from.
>
> The build is already much closer to a multi-release model than a single
> release model.
>
> I've diffed what I have so far and attached it to ARIES-173. It includes
> scm info and a lot of version corrections. Due to the failing tests I'm not
> too comfortable committing it.
>
> Is anyone else seeing test failures locally?
>
> thanks
> david jencks
>
> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>
>> Hi David,
>>
>> It 'd be great if you are willing to fix these build issues, since you
>> just went through a big release in Geronimo. :)
>>
>> I know the maven release plugin isn't friendly to use some cases, so
>> it is best we get these resolved to make our release process a bit
>> easier.
>>
>> EBA plugin would be a very nice add-on, if it comes in time with the
>> release.
>>
>> Thanks
>>
>> Lin
>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>>
>>>> I would like to understand the problems you see better, but I do not
>>>> have
>>>> the maven background you guys have, any chance you could explain what
>>>> the
>>>> problems are, why they are problems and the solution at some point?
>>>
>>> The biggest immediate problem is that without correct svn info you can't
>>> do
>>> a release with the release plugin. I'm pretty sure the way its set up
>>> now,
>>> when you try, the tag will be under maven's apache pom, not aries.
>>> (you'll
>>> fail unless you happen to be a maven committer too). You definitely don't
>>> want to try to do a release without the release plugin.
>>>
>>> Organizationally there's no way that for instance blueprint, application,
>>> and samples should always be released in synchrony. Any time two of them
>>> happen to be ready for release at the same time it will be purely
>>> accidental. Right now everyone wants to get a milestone out the door,
>>> but
>>> looking at the different projects their state of completion is pretty
>>> much
>>> wildly different. A decision to release all of them at once is not based
>>> in
>>> any way on them being equally complete. I'm suggesting that since build
>>> fixes are needed anyway, why not set up a maintainable structure that
>>> will
>>> continue to work beyond this publicity release. The benefit to users is
>>> that aries will be able to release bits in a timely fashion; otherwise
>>> the
>>> entire project will never be in a releasable state at once. (I'm only
>>> exaggerating a little bit :-)
>>>
>>> What got me looking at this at all is what look like wild gyrations that
>>> don't really use maven properly to get an .eba (or some artifact) out the
>>> door. This might be ok for one release but (a) I think this can be done
>>> directly with the assembly plugin short term and (b) an eba-maven-plugin
>>> seems like the obvious more long term solution.
>>>
>>> I'm willing to fix the build and probably work on an eba plugin, but want
>>> to
>>> be sure this is ok with everyone first.
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Thanks
>>>> Alasdair
>>>>
>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com> wrote:
>>>>
>>>>> This discussion got me worried enough to take a look at the aries
>>>>> build.
>>>>> Now I'm even more worried.
>>>>>
>>>>> While it might feel good to try to push out a release as fast as
>>>>> possible
>>>>> I'd prefer to see a sustainable build system in place first. So far it
>>>>> looks to me as if aries is going to be a bunch of loosely coupled
>>>>> subprojects. Building them all at once is not going to work for long.
>>>>> I
>>>>> think we should recognize that and put that in the build system now.
>>>>> To me
>>>>> this means:
>>>>>
>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>> (mostly
>>>>> svn info) (right now this is completely missing everywhere as far as I
>>>>> can
>>>>> see, which will result in ares getting tagged into svn as part of the
>>>>> apache
>>>>> pom)
>>>>>
>>>>> We can still have a "fake" pom that builds everything, but it won't be
>>>>> part of any release procedure.
>>>>>
>>>>> Having separately released subprojects does not prevent having a single
>>>>> vote on all the releases.
>>>>>
>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>
>>>>> In addition relevant to this particular bit of the thread, we need an
>>>>> eba-maven-plugin to assemble ebas. Getting this into a first release
>>>>> would
>>>>> be a great idea IMO.
>>>>>
>>>>> If there's general agreement I can spend some time playing with the
>>>>> build
>>>>> and possibly working on the eba plugin.
>>>>>
>>>>> thoughts?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>>
>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I'd also like to see us release the sample applications but I think
>>>>>>>> there is
>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>> generate
>>>>>>>> EBAs
>>>>>>>> using different techniques - but both leverage the
>>>>>>>> maven-antrun-plugin
>>>>>>>> to
>>>>>>>> finally produce a file of type "eba".
>>>>>>>
>>>>>>> I realised the .eba file generated in the blog-assembly module wasn't
>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>> pom.xml
>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>>>>>>> artifact and the build-helper-maven-plugin to push the artifact to
>>>>>>> the
>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba for
>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>
>>>>>> I've not used the build-helper-maven-plugin before. Do you know if it
>>>>>> will work with the maven-release-plugin to push the eba artifacts when
>>>>>> we do
>>>>>> a release? If so, then I should look at using the same mechanism for
>>>>>> AriesTrader.
>>>>>>
>>>>>>>> I think the result is that the eba will not be available in a maven
>>>>>>>> repository.
>>>>>>>>
>>>>>>>> One of the differences is that AriesTrader first generates a jar
>>>>>>>> using
>>>>>>>> the
>>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar will
>>>>>>>> be
>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>> "application"
>>>>>>>> even
>>>>>>>> with an extension of "jar" rather than "eba". If that is correct
>>>>>>>> then
>>>>>>>> perhaps delivery of an application jar is an acceptable approach for
>>>>>>>> the 1st
>>>>>>>> release. Unfortunately I haven't actually setup my equinox assembly
>>>>>>>> to
>>>>>>>> deploy the eba yet - it still deploys all of the individual bundles.
>>>>>>>
>>>>>>> Using the maven-assembly-plugin likely the preferred approach long
>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>>> control and add the .eba one?
>>>>>>
>>>>>> I can give this a try for AriesTrader. If it doesn't work out - is
>>>>>> there anything wrong with the approach I mentioned earlier of just
>>>>>> using the
>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>> application
>>>>>> support only look at *.eba archives?
>>>>>>
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>
>>>>>>>>> I'd like to see at least those included:
>>>>>>>>> * blueprint
>>>>>>>>> * jmx
>>>>>>>>> * jndi
>>>>>>>>> * transaction
>>>>>>>>>
>>>>>>>>> I don't think applications are really usable yet and I haven't
>>>>>>>>> really
>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>> The transaction component is functional and we've been using it
>>>>>>>>> mostly
>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>> Do you have any particular concerns with it ? (I'm not talking
>>>>>>>>> about
>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>
>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>>> volunteering
>>>>>>>>>> to be the release manager. Your response helps me get a better
>>>>>>>>>> picture
>>>>>>>>>> of
>>>>>>>>>> the plans.
>>>>>>>>>>
>>>>>>>>>> I was really just interested in the general objectives and timing
>>>>>>>>>> since
>>>>>>>>>> it
>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb means it
>>>>>>>>>> will
>>>>>>>>>> be
>>>>>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>>>>>> steep to
>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>
>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>> everybody
>>>>>>>>>> thinking
>>>>>>>>>> and planning along the same lines (or understand quickly if there
>>>>>>>>>> are any
>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>> creating
>>>>>>>>>> a
>>>>>>>>>> release candidate next week means that we should be getting more
>>>>>>>>>> restrictive
>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>
>>>>>>>>>> I don't have any strong opinions on what should be in or out - but
>>>>>>>>>> in
>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>> functional.
>>>>>>>>>> At
>>>>>>>>>> the moment I'm not sure what those are - but I suspect not all of
>>>>>>>>>> the
>>>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out
>>>>>>>>>>> on
>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>
>>>>>>>>>>> Personally, I think the 0.1 release should serve to get what we
>>>>>>>>>>> have
>>>>>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>>>>>> haves'
>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>> distribution
>>>>>>>>>>> files that are acceptable to the IPMC. I think each main area of
>>>>>>>>>>> the
>>>>>>>>>>> code deserves at least a README to describe what's possible.
>>>>>>>>>>> Since
>>>>>>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>>>>>>> timing I hope/expect to get the release out this in feb. If there
>>>>>>>>>>> are
>>>>>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>>>>>> please
>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>>>>>>> target
>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a
>>>>>>>>>>> new
>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Jeremy
>>>>>>>>>>>
>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>
>>>>>>>>>>>> What are your current thoughts and goals regarding the release
>>>>>>>>>>>> and
>>>>>>>>>>>> potential
>>>>>>>>>>>> target dates?
>>>>>>>>>>>>
>>>>>>>>>>>> I think it would be good if you could summarize your thoughts in
>>>>>>>>>>>> an
>>>>>>>>>>>> email
>>>>>>>>>>>> or
>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we
>>>>>>>>>>>> make
>>>>>>>>>>>> progress.
>>>>>>>>>>>> Of particular interest would be the content that we would like
>>>>>>>>>>>> to
>>>>>>>>>>>> see
>>>>>>>>>>>> in
>>>>>>>>>>>> the first release (clarifying what we consider "must have" from
>>>>>>>>>>>> "nice
>>>>>>>>>>>> to
>>>>>>>>>>>> have"), the current status of that content, target dates for the
>>>>>>>>>>>> release,
>>>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting to put
>>>>>>>>>>>>>> those
>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>>> process
>>>>>>>>>>>>> has
>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>
>>>
>>>
>
>
Re: [DISCUSSION] Aries release
Posted by Guillaume Nodet <gn...@gmail.com>.
On Thu, Feb 25, 2010 at 08:55, David Jencks <da...@yahoo.com> wrote:
> I started looking into cleaning up the build, and of course it is taking
> longer than I expected.
>
> I'm seriously hampered by failing tests in a fresh checkout.
>
> There are some projects in application that stop compiling if you
> alphabetize the dependencies. It looks like osgi 3 artifacts are getting on
> the maven classpath before osgi 4.2 artifacts. Adding exclusions to the
> dependencies seems to fix it if you can figure out where the out of date
> jars are coming from.
>
Have you tried
mvn dependency:tree
This usually helps *a lot* with such issues
> The build is already much closer to a multi-release model than a single
> release model.
>
> I've diffed what I have so far and attached it to ARIES-173. It includes
> scm info and a lot of version corrections. Due to the failing tests I'm not
> too comfortable committing it.
>
> Is anyone else seeing test failures locally?
>
> thanks
> david jencks
>
> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>
>> Hi David,
>>
>> It 'd be great if you are willing to fix these build issues, since you
>> just went through a big release in Geronimo. :)
>>
>> I know the maven release plugin isn't friendly to use some cases, so
>> it is best we get these resolved to make our release process a bit
>> easier.
>>
>> EBA plugin would be a very nice add-on, if it comes in time with the
>> release.
>>
>> Thanks
>>
>> Lin
>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>>
>>>> I would like to understand the problems you see better, but I do not
>>>> have
>>>> the maven background you guys have, any chance you could explain what
>>>> the
>>>> problems are, why they are problems and the solution at some point?
>>>
>>> The biggest immediate problem is that without correct svn info you can't
>>> do
>>> a release with the release plugin. I'm pretty sure the way its set up
>>> now,
>>> when you try, the tag will be under maven's apache pom, not aries.
>>> (you'll
>>> fail unless you happen to be a maven committer too). You definitely don't
>>> want to try to do a release without the release plugin.
>>>
>>> Organizationally there's no way that for instance blueprint, application,
>>> and samples should always be released in synchrony. Any time two of them
>>> happen to be ready for release at the same time it will be purely
>>> accidental. Right now everyone wants to get a milestone out the door,
>>> but
>>> looking at the different projects their state of completion is pretty
>>> much
>>> wildly different. A decision to release all of them at once is not based
>>> in
>>> any way on them being equally complete. I'm suggesting that since build
>>> fixes are needed anyway, why not set up a maintainable structure that
>>> will
>>> continue to work beyond this publicity release. The benefit to users is
>>> that aries will be able to release bits in a timely fashion; otherwise
>>> the
>>> entire project will never be in a releasable state at once. (I'm only
>>> exaggerating a little bit :-)
>>>
>>> What got me looking at this at all is what look like wild gyrations that
>>> don't really use maven properly to get an .eba (or some artifact) out the
>>> door. This might be ok for one release but (a) I think this can be done
>>> directly with the assembly plugin short term and (b) an eba-maven-plugin
>>> seems like the obvious more long term solution.
>>>
>>> I'm willing to fix the build and probably work on an eba plugin, but want
>>> to
>>> be sure this is ok with everyone first.
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Thanks
>>>> Alasdair
>>>>
>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com> wrote:
>>>>
>>>>> This discussion got me worried enough to take a look at the aries
>>>>> build.
>>>>> Now I'm even more worried.
>>>>>
>>>>> While it might feel good to try to push out a release as fast as
>>>>> possible
>>>>> I'd prefer to see a sustainable build system in place first. So far it
>>>>> looks to me as if aries is going to be a bunch of loosely coupled
>>>>> subprojects. Building them all at once is not going to work for long.
>>>>> I
>>>>> think we should recognize that and put that in the build system now.
>>>>> To me
>>>>> this means:
>>>>>
>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>> (mostly
>>>>> svn info) (right now this is completely missing everywhere as far as I
>>>>> can
>>>>> see, which will result in ares getting tagged into svn as part of the
>>>>> apache
>>>>> pom)
>>>>>
>>>>> We can still have a "fake" pom that builds everything, but it won't be
>>>>> part of any release procedure.
>>>>>
>>>>> Having separately released subprojects does not prevent having a single
>>>>> vote on all the releases.
>>>>>
>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>
>>>>> In addition relevant to this particular bit of the thread, we need an
>>>>> eba-maven-plugin to assemble ebas. Getting this into a first release
>>>>> would
>>>>> be a great idea IMO.
>>>>>
>>>>> If there's general agreement I can spend some time playing with the
>>>>> build
>>>>> and possibly working on the eba plugin.
>>>>>
>>>>> thoughts?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>>
>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I'd also like to see us release the sample applications but I think
>>>>>>>> there is
>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>> generate
>>>>>>>> EBAs
>>>>>>>> using different techniques - but both leverage the
>>>>>>>> maven-antrun-plugin
>>>>>>>> to
>>>>>>>> finally produce a file of type "eba".
>>>>>>>
>>>>>>> I realised the .eba file generated in the blog-assembly module wasn't
>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>> pom.xml
>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>>>>>>> artifact and the build-helper-maven-plugin to push the artifact to
>>>>>>> the
>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba for
>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>
>>>>>> I've not used the build-helper-maven-plugin before. Do you know if it
>>>>>> will work with the maven-release-plugin to push the eba artifacts when
>>>>>> we do
>>>>>> a release? If so, then I should look at using the same mechanism for
>>>>>> AriesTrader.
>>>>>>
>>>>>>>> I think the result is that the eba will not be available in a maven
>>>>>>>> repository.
>>>>>>>>
>>>>>>>> One of the differences is that AriesTrader first generates a jar
>>>>>>>> using
>>>>>>>> the
>>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar will
>>>>>>>> be
>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>> "application"
>>>>>>>> even
>>>>>>>> with an extension of "jar" rather than "eba". If that is correct
>>>>>>>> then
>>>>>>>> perhaps delivery of an application jar is an acceptable approach for
>>>>>>>> the 1st
>>>>>>>> release. Unfortunately I haven't actually setup my equinox assembly
>>>>>>>> to
>>>>>>>> deploy the eba yet - it still deploys all of the individual bundles.
>>>>>>>
>>>>>>> Using the maven-assembly-plugin likely the preferred approach long
>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>>> control and add the .eba one?
>>>>>>
>>>>>> I can give this a try for AriesTrader. If it doesn't work out - is
>>>>>> there anything wrong with the approach I mentioned earlier of just
>>>>>> using the
>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>> application
>>>>>> support only look at *.eba archives?
>>>>>>
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>
>>>>>>>>> I'd like to see at least those included:
>>>>>>>>> * blueprint
>>>>>>>>> * jmx
>>>>>>>>> * jndi
>>>>>>>>> * transaction
>>>>>>>>>
>>>>>>>>> I don't think applications are really usable yet and I haven't
>>>>>>>>> really
>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>> The transaction component is functional and we've been using it
>>>>>>>>> mostly
>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>> Do you have any particular concerns with it ? (I'm not talking
>>>>>>>>> about
>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>
>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>>> volunteering
>>>>>>>>>> to be the release manager. Your response helps me get a better
>>>>>>>>>> picture
>>>>>>>>>> of
>>>>>>>>>> the plans.
>>>>>>>>>>
>>>>>>>>>> I was really just interested in the general objectives and timing
>>>>>>>>>> since
>>>>>>>>>> it
>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb means it
>>>>>>>>>> will
>>>>>>>>>> be
>>>>>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>>>>>> steep to
>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>
>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>> everybody
>>>>>>>>>> thinking
>>>>>>>>>> and planning along the same lines (or understand quickly if there
>>>>>>>>>> are any
>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>> creating
>>>>>>>>>> a
>>>>>>>>>> release candidate next week means that we should be getting more
>>>>>>>>>> restrictive
>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>
>>>>>>>>>> I don't have any strong opinions on what should be in or out - but
>>>>>>>>>> in
>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>> functional.
>>>>>>>>>> At
>>>>>>>>>> the moment I'm not sure what those are - but I suspect not all of
>>>>>>>>>> the
>>>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out
>>>>>>>>>>> on
>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>
>>>>>>>>>>> Personally, I think the 0.1 release should serve to get what we
>>>>>>>>>>> have
>>>>>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>>>>>> haves'
>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>> distribution
>>>>>>>>>>> files that are acceptable to the IPMC. I think each main area of
>>>>>>>>>>> the
>>>>>>>>>>> code deserves at least a README to describe what's possible.
>>>>>>>>>>> Since
>>>>>>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>>>>>>> timing I hope/expect to get the release out this in feb. If there
>>>>>>>>>>> are
>>>>>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>>>>>> please
>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>>>>>>> target
>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a
>>>>>>>>>>> new
>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Jeremy
>>>>>>>>>>>
>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>
>>>>>>>>>>>> What are your current thoughts and goals regarding the release
>>>>>>>>>>>> and
>>>>>>>>>>>> potential
>>>>>>>>>>>> target dates?
>>>>>>>>>>>>
>>>>>>>>>>>> I think it would be good if you could summarize your thoughts in
>>>>>>>>>>>> an
>>>>>>>>>>>> email
>>>>>>>>>>>> or
>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we
>>>>>>>>>>>> make
>>>>>>>>>>>> progress.
>>>>>>>>>>>> Of particular interest would be the content that we would like
>>>>>>>>>>>> to
>>>>>>>>>>>> see
>>>>>>>>>>>> in
>>>>>>>>>>>> the first release (clarifying what we consider "must have" from
>>>>>>>>>>>> "nice
>>>>>>>>>>>> to
>>>>>>>>>>>> have"), the current status of that content, target dates for the
>>>>>>>>>>>> release,
>>>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting to put
>>>>>>>>>>>>>> those
>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>>> process
>>>>>>>>>>>>> has
>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>
>>>
>>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
On Mar 2, 2010, at 2:28 PM, Jeremy Hughes wrote:
> On 2 March 2010 19:06, David Jencks <da...@yahoo.com> wrote:
>>
>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>>
>>> I agree that we should make a global change to 0.1-incubating-
>>> SNAPSHOT
>>> first. Why wouldn't we just do that now?
>>
>> I started doing some experiments here...
>>
>> running
>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>>
>> in root and parent upgrades everything maven knows about just fine.
>> However
>> there's (1) mentioned below and also a hardcoded version in two
>> blueprint-itests.
>>
>> According to
>>
>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven
>> +Plugin
>>
>> we should be able to replace the hardcoded versions with
>> .versionAsInProject()
>>
>> if we run the maven-paxexam-plugin on the project. However I can't
>> get it to
>> work yet.
>>>
>>> Just a heads-up on some other issues related to versions in
>>> samples. There
>>> are two potential problems that I am aware of:
>>>
>>> 1) For both Blog-Sample and AriesTrader there are hard-coded
>>> version
>>> references in the Equinox assembly config.ini file which are used
>>> to specify
>>> the bundle jars that are to be started for the assembly.
>>> Naturally, the
>>> versions of the aries bundles in this file won't be updated by the
>>> maven-release-plugin. I'm not sure of a good solution for this
>>> beyond just
>>> manually changing the config.ini files prior to creating a release
>>> candidate.
>>
>> I think we might be able to work around this by putting the
>> config.ini files
>> in src/main/resources/filtered-resources and defining a bunch of
>> properties
>> in an appropriate pom and using them for the version imports of the
>> aries
>> subproject dependencyManagement imports in the samples root pom. I
>> haven't
>> tried this yet...
>>
>
> I'm learning ... just looked up filtering resources and this would
> definitely seem to fit the bill.
>
>>>
>>> 2) I think there is still an unresolved issue related to Blog-
>>> Sample and
>>> how we might be able to demonstrate a bundle upgrade scenario.
>>> I'm not
>>> sure if this capability is included yet in Blog-Sample - so it
>>> might still
>>> be a non-issue at the moment. However, we had some discussion on
>>> this a
>>> week ago or so related to how we might be able to include multiple
>>> versions
>>> of components in the sample so that an upgrade scenario could be
>>> demonstrated. If that is still a goal for the 0.1 release we will
>>> need to
>>> come up with some solution.
>>
>> no ideas from me on this one :-)
>
> I had a feeling Zoe was doing something in this area when she created
> the blog-persistence_1.0.0 directory but it's empty.
>
> Zoe, with ARIES-199 did you check in the code for the JPA persistence
> impl then back it out because it went in over the JDBC one. I was
> wondering what your plan for adding in the JPA persistence impl again
> - in the blog-persistence_1.0.0 dir perhaps which is empty right now.
>
> I think the Blog sample bundles should not be marked 0.1. The sample
> will show how a blog-persistence bundle at version 1.1.0 can be used
> to update an .eba that only uses blog-persistence at version 1.0. So
> these bundles need to be versioned independently of Aries itself. As
> part of the release of the blog sample there should be a .eba artifact
> containing the blog bundles including the blog persistence bundle at
> version 1.0.0. There should be an artifact that contains the blog
> persistence bundle at version 1.1.0 - but that isn't a .eba - it
> should probably just be a zip.
>
> So I think the maven-release-plugin needs to pass over the Blog sample
> bundles and run on the blog assembly project to create a .eba at
> 0.1-incubating containing bundles created from the other modules at
> version 1.0.0 (no incubating). The Apache release process requires
> each released artifact to contain NOTICE, LICENSE and have incubating
> in the artifact's name. Which means we can't release the blog sample
> bundles directly because they need to be at version 1.0.0 and 1.1.0.
We have lots of version segments, cant we show how to replace
0.1.0.incubating
with
0.1.1.incubating?
In any case it looks like we may want to override the
autoVersionSubmodules for at least part of the blog sample. It is a
real pain to release correctly then, though.
thanks
david jencks
>
>>
>> thanks
>> david jencks
>>
>>>
>>> Joe
>>>
>>>
>>> David Jencks wrote:
>>>>
>>>> I think everything is ok.... I think (at least with dryRun=true)
>>>> that the
>>>> release plugin builds the project first as-is and checks that
>>>> signing etc
>>>> works.
>>>> I added autoVersionSubmodules=true in the root parent pom which
>>>> will make
>>>> things work more smoothly :-)
>>>> I really recommend changing the version to 0.1-incubating-
>>>> SNAPSHOT first,
>>>> I'm happy to do this if you want.
>>>> thanks
>>>> david jencks
>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>>
>>>>> scratch that. I'm working thru this:
>>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>>> there's several steps I haven't done.
>>>>>
>>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>>
>>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> I've done most of what I think is needed for aries to be
>>>>>>> basically
>>>>>>> releasable. There are some bits left and possibly stuff I've
>>>>>>> missed.
>>>>>>>
>>>>>>> 1. legal file review. There are a bunch of NOTICE files that
>>>>>>> claim
>>>>>>> that
>>>>>>> work from osgi is included. Really? license and notice files
>>>>>>> are
>>>>>>> supposed
>>>>>>> to apply to what is actually in an artifact or checkout. Are
>>>>>>> some of
>>>>>>> our
>>>>>>> source files copied from an osgi source? Also all the legal
>>>>>>> files
>>>>>>> that end
>>>>>>> up in binary artifacts need to be checked. Also we need to
>>>>>>> run the
>>>>>>> rat
>>>>>>> plugin: this should be configured in the default pom. Not
>>>>>>> sure if I
>>>>>>> will
>>>>>>> get to this.
>>>>>>>
>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure
>>>>>>> how to
>>>>>>> make
>>>>>>> sure that an eba is working so I didn't mess with this. I
>>>>>>> think the
>>>>>>> plugin
>>>>>>> itself is working well enough to use though.
>>>>>>>
>>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>>> convenient to
>>>>>>> have these alphabetized so I can find what I'm looking for,
>>>>>>> but I
>>>>>>> haven't
>>>>>>> done this in most poms. I'm not sure why there isn't a usable
>>>>>>> tool
>>>>>>> for
>>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>>
>>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>>> dependency:analyze and
>>>>>>> look carefully at the results. The results from this can
>>>>>>> require
>>>>>>> interpretation so its best if someone who is very familiar
>>>>>>> with how
>>>>>>> the code
>>>>>>> works does this.
>>>>>>>
>>>>>>> 4. before a release all snapshots need to be resolved to
>>>>>>> released
>>>>>>> versions.
>>>>>>> I don't know if there are any snapshots.
>>>>>>>
>>>>>>> To summarize what I've tried to do:
>>>>>>>
>>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>>> dependencies
>>>>>>> that all projects are pretty sure to use including the pax
>>>>>>> stuff used
>>>>>>> mostly
>>>>>>> for testing.
>>>>>>>
>>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>>
>>>>>>> 3. each subproject has an scm element in its pom, but no
>>>>>>> others do.
>>>>>>>
>>>>>>> 4. each subproject has dependency management for everything
>>>>>>> included
>>>>>>> in it.
>>>>>>> In addition, it has its subprojects listed in dependency
>>>>>>> management.
>>>>>>> (this
>>>>>>> is bent slightly for the samples). This means that
>>>>>>> (a) modules in a subproject don't need to include versions for
>>>>>>> use of
>>>>>>> other
>>>>>>> modules
>>>>>>> (b) you can get dependency management for all the modules in a
>>>>>>> subproject
>>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>>> samples pom
>>>>>>> for an example).
>>>>>>>
>>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>>> dependency
>>>>>>> elements.
>>>>>>>
>>>>>>> Release is going to involve...
>>>>>>>
>>>>>>> releasing the parent
>>>>>>
>>>>>> In trunk/parent I tried:
>>>>>>
>>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>>
>>>>>> Providing 0.1-incubating for the release version
>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development
>>>>>> version
>>>>>>
>>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>>
>>>>>> [INFO] [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>>> [INFO] [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [INFO] [INFO] [clean:clean]
>>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class
>>>>>> =>
>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on =>
>>>>>> 'false'.
>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>>> 'false'.
>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>>> [INFO] [INFO] [assembly:single {execution: source-release-
>>>>>> assembly}]
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>> skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>> added,
>>>>>> skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>> added,
>>>>>> skipping
>>>>>> [INFO] [INFO] Building zip:
>>>>>>
>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target
>>>>>> \parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>> skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>> added,
>>>>>> skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>> added,
>>>>>> skipping
>>>>>> [INFO] [INFO] Preparing source:jar
>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>>> recursive invocation.
>>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>>> classpath-capable package
>>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>>
>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>>
>>>>>> Then stops at the gpg stage. I thought it would prompt me for
>>>>>> my key
>>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>>
>>>>>>> updating the parent version wherever it is used (all subproject
>>>>>>> parents)
>>>>>>>
>>>>>>> releasing the subprojects in an appropriate order and updating
>>>>>>> their
>>>>>>> versions wherever they are used.
>>>>>>>
>>>>>>> It might be worthwhile changing the pom version to
>>>>>>> 0.1-incubating-SNAPSHOT
>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing
>>>>>>> this
>>>>>>> because
>>>>>>> then the versions plugin can be used to update use of a
>>>>>>> subproject to
>>>>>>> the
>>>>>>> newly released version of what it uses. Going from
>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>>
>>>>>>> As noted in the "root" pom, don't try to release the root pom
>>>>>>> and
>>>>>>> don't try
>>>>>>> release everything at once from the root pom.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>>
>>>>>>>> I started looking into cleaning up the build, and of course
>>>>>>>> it is
>>>>>>>> taking
>>>>>>>> longer than I expected.
>>>>>>>>
>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>>
>>>>>>>> There are some projects in application that stop compiling if
>>>>>>>> you
>>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts
>>>>>>>> are
>>>>>>>> getting on
>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding
>>>>>>>> exclusions to
>>>>>>>> the
>>>>>>>> dependencies seems to fix it if you can figure out where the
>>>>>>>> out of
>>>>>>>> date
>>>>>>>> jars are coming from.
>>>>>>>>
>>>>>>>> The build is already much closer to a multi-release model
>>>>>>>> than a
>>>>>>>> single
>>>>>>>> release model.
>>>>>>>>
>>>>>>>> I've diffed what I have so far and attached it to ARIES-173.
>>>>>>>> It
>>>>>>>> includes
>>>>>>>> scm info and a lot of version corrections. Due to the
>>>>>>>> failing tests
>>>>>>>> I'm not
>>>>>>>> too comfortable committing it.
>>>>>>>>
>>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>>
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> It 'd be great if you are willing to fix these build issues,
>>>>>>>>> since
>>>>>>>>> you
>>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>>
>>>>>>>>> I know the maven release plugin isn't friendly to use some
>>>>>>>>> cases, so
>>>>>>>>> it is best we get these resolved to make our release process
>>>>>>>>> a bit
>>>>>>>>> easier.
>>>>>>>>>
>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time
>>>>>>>>> with the
>>>>>>>>> release.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Lin
>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>>> <da...@yahoo.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I would like to understand the problems you see better,
>>>>>>>>>>> but I do
>>>>>>>>>>> not
>>>>>>>>>>> have
>>>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>>>> explain
>>>>>>>>>>> what
>>>>>>>>>>> the
>>>>>>>>>>> problems are, why they are problems and the solution at some
>>>>>>>>>>> point?
>>>>>>>>>>
>>>>>>>>>> The biggest immediate problem is that without correct svn
>>>>>>>>>> info you
>>>>>>>>>> can't
>>>>>>>>>> do
>>>>>>>>>> a release with the release plugin. I'm pretty sure the way
>>>>>>>>>> its set
>>>>>>>>>> up
>>>>>>>>>> now,
>>>>>>>>>> when you try, the tag will be under maven's apache pom, not
>>>>>>>>>> aries.
>>>>>>>>>> (you'll
>>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>>> definitely
>>>>>>>>>> don't
>>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>>
>>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>>> application,
>>>>>>>>>> and samples should always be released in synchrony. Any
>>>>>>>>>> time two
>>>>>>>>>> of
>>>>>>>>>> them
>>>>>>>>>> happen to be ready for release at the same time it will be
>>>>>>>>>> purely
>>>>>>>>>> accidental. Right now everyone wants to get a milestone
>>>>>>>>>> out the
>>>>>>>>>> door,
>>>>>>>>>> but
>>>>>>>>>> looking at the different projects their state of completion
>>>>>>>>>> is
>>>>>>>>>> pretty
>>>>>>>>>> much
>>>>>>>>>> wildly different. A decision to release all of them at
>>>>>>>>>> once is not
>>>>>>>>>> based in
>>>>>>>>>> any way on them being equally complete. I'm suggesting
>>>>>>>>>> that since
>>>>>>>>>> build
>>>>>>>>>> fixes are needed anyway, why not set up a maintainable
>>>>>>>>>> structure
>>>>>>>>>> that
>>>>>>>>>> will
>>>>>>>>>> continue to work beyond this publicity release. The
>>>>>>>>>> benefit to
>>>>>>>>>> users is
>>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>>> otherwise
>>>>>>>>>> the
>>>>>>>>>> entire project will never be in a releasable state at once.
>>>>>>>>>> (I'm
>>>>>>>>>> only
>>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>>
>>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>>> gyrations
>>>>>>>>>> that
>>>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>>>> artifact)
>>>>>>>>>> out
>>>>>>>>>> the
>>>>>>>>>> door. This might be ok for one release but (a) I think
>>>>>>>>>> this can be
>>>>>>>>>> done
>>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>>> eba-maven-plugin
>>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>>
>>>>>>>>>> I'm willing to fix the build and probably work on an eba
>>>>>>>>>> plugin,
>>>>>>>>>> but
>>>>>>>>>> want to
>>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Alasdair
>>>>>>>>>>>
>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <david_jencks@yahoo.com
>>>>>>>>>>> >
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> This discussion got me worried enough to take a look at
>>>>>>>>>>>> the aries
>>>>>>>>>>>> build.
>>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>>
>>>>>>>>>>>> While it might feel good to try to push out a release as
>>>>>>>>>>>> fast as
>>>>>>>>>>>> possible
>>>>>>>>>>>> I'd prefer to see a sustainable build system in place
>>>>>>>>>>>> first. So
>>>>>>>>>>>> far
>>>>>>>>>>>> it
>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>>> coupled
>>>>>>>>>>>> subprojects. Building them all at once is not going to
>>>>>>>>>>>> work for
>>>>>>>>>>>> long.
>>>>>>>>>>>> I
>>>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>>>> system
>>>>>>>>>>>> now.
>>>>>>>>>>>> To me
>>>>>>>>>>>> this means:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>>>>>> released
>>>>>>>>>>>> (mostly
>>>>>>>>>>>> svn info) (right now this is completely missing
>>>>>>>>>>>> everywhere as
>>>>>>>>>>>> far as
>>>>>>>>>>>> I can
>>>>>>>>>>>> see, which will result in ares getting tagged into svn as
>>>>>>>>>>>> part of
>>>>>>>>>>>> the
>>>>>>>>>>>> apache
>>>>>>>>>>>> pom)
>>>>>>>>>>>>
>>>>>>>>>>>> We can still have a "fake" pom that builds everything,
>>>>>>>>>>>> but it
>>>>>>>>>>>> won't be
>>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>>
>>>>>>>>>>>> Having separately released subprojects does not prevent
>>>>>>>>>>>> having a
>>>>>>>>>>>> single
>>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>>
>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using
>>>>>>>>>>>> resources and
>>>>>>>>>>>> filtered-resources to distinguish when filtering is
>>>>>>>>>>>> called for.
>>>>>>>>>>>>
>>>>>>>>>>>> In addition relevant to this particular bit of the
>>>>>>>>>>>> thread, we
>>>>>>>>>>>> need an
>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a
>>>>>>>>>>>> first
>>>>>>>>>>>> release
>>>>>>>>>>>> would
>>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>>
>>>>>>>>>>>> If there's general agreement I can spend some time
>>>>>>>>>>>> playing with
>>>>>>>>>>>> the
>>>>>>>>>>>> build
>>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>>
>>>>>>>>>>>> thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>> thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd also like to see us release the sample
>>>>>>>>>>>>>>> applications but I
>>>>>>>>>>>>>>> think
>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and
>>>>>>>>>>>>>>> AriesTrader
>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly
>>>>>>>>>>>>>> module
>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>> being pushed into my local repo. I've made some changes
>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to
>>>>>>>>>>>>>> create the
>>>>>>>>>>>>>> .eba
>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>>> artifact
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> .eba for
>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do
>>>>>>>>>>>>> you know
>>>>>>>>>>>>> if
>>>>>>>>>>>>> it
>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>> when we do
>>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>>> mechanism for
>>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think the result is that the eba will not be
>>>>>>>>>>>>>>> available in a
>>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> One of the differences is that AriesTrader first
>>>>>>>>>>>>>>> generates a
>>>>>>>>>>>>>>> jar
>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba.
>>>>>>>>>>>>>>> The jar
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that
>>>>>>>>>>>>>>> is
>>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my
>>>>>>>>>>>>>>> equinox
>>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the
>>>>>>>>>>>>>>> individual
>>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>> long
>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and
>>>>>>>>>>>>>> use the
>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact
>>>>>>>>>>>>>> from
>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't
>>>>>>>>>>>>> work out -
>>>>>>>>>>>>> is
>>>>>>>>>>>>> there anything wrong with the approach I mentioned
>>>>>>>>>>>>> earlier of
>>>>>>>>>>>>> just
>>>>>>>>>>>>> using the
>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the
>>>>>>>>>>>>> current
>>>>>>>>>>>>> application
>>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>>> The transaction component is functional and we've
>>>>>>>>>>>>>>>> been using
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <joebohn@gmail.com
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for the response (even while on
>>>>>>>>>>>>>>>>> vacation!) ... and
>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me
>>>>>>>>>>>>>>>>> get a
>>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I was really just interested in the general
>>>>>>>>>>>>>>>>> objectives and
>>>>>>>>>>>>>>>>> timing
>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out
>>>>>>>>>>>>>>>>> in Feb
>>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>>>>> little
>>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The more communication the better. It's important
>>>>>>>>>>>>>>>>> to get
>>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>> and planning along the same lines (or understand
>>>>>>>>>>>>>>>>> quickly if
>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are
>>>>>>>>>>>>>>>>> thinking of
>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>>>> getting
>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be
>>>>>>>>>>>>>>>>> in or out
>>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> general it doesn't make sense to release things that
>>>>>>>>>>>>>>>>> aren't
>>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I
>>>>>>>>>>>>>>>>> suspect not
>>>>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday
>>>>>>>>>>>>>>>>>> but am
>>>>>>>>>>>>>>>>>> now out
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to
>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires.
>>>>>>>>>>>>>>>>>> So
>>>>>>>>>>>>>>>>>> 'must
>>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each
>>>>>>>>>>>>>>>>>> main
>>>>>>>>>>>>>>>>>> area of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>>>> unknowns -
>>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in
>>>>>>>>>>>>>>>>>> feb. If
>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version
>>>>>>>>>>>>>>>>>> 1.0 to 0.1
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> target a
>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <joebohn@gmail.com
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep
>>>>>>>>>>>>>>>>>>> updated as
>>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that
>>>>>>>>>>>>>>>>>>> we would
>>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider
>>>>>>>>>>>>>>>>>>> "must have"
>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>>>>>> dates
>>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need
>>>>>>>>>>>>>>>>>>>>> any help.
>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>>>> interesting
>>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one
>>>>>>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release
>>>>>>>>>>>>>>>>>>>>>> manager.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release
>>>>>>>>>>>>>>>>>>>>>>> with all
>>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint
>>>>>>>>>>>>>>>>>>>>>>> release as an
>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache
>>>>>>>>>>>>>>>>>>>>>>> release is
>>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to
>>>>>>>>>>>>>>>>>>>>>>> see this
>>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>>
>>> --
>>> Joe
>>
>>
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 2 March 2010 19:06, David Jencks <da...@yahoo.com> wrote:
>
> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>
>> I agree that we should make a global change to 0.1-incubating-SNAPSHOT
>> first. Why wouldn't we just do that now?
>
> I started doing some experiments here...
>
> running
> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>
> in root and parent upgrades everything maven knows about just fine. However
> there's (1) mentioned below and also a hardcoded version in two
> blueprint-itests.
>
> According to
>
> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>
> we should be able to replace the hardcoded versions with
> .versionAsInProject()
>
> if we run the maven-paxexam-plugin on the project. However I can't get it to
> work yet.
>>
>> Just a heads-up on some other issues related to versions in samples. There
>> are two potential problems that I am aware of:
>>
>> 1) For both Blog-Sample and AriesTrader there are hard-coded version
>> references in the Equinox assembly config.ini file which are used to specify
>> the bundle jars that are to be started for the assembly. Naturally, the
>> versions of the aries bundles in this file won't be updated by the
>> maven-release-plugin. I'm not sure of a good solution for this beyond just
>> manually changing the config.ini files prior to creating a release
>> candidate.
>
> I think we might be able to work around this by putting the config.ini files
> in src/main/resources/filtered-resources and defining a bunch of properties
> in an appropriate pom and using them for the version imports of the aries
> subproject dependencyManagement imports in the samples root pom. I haven't
> tried this yet...
>
I'm learning ... just looked up filtering resources and this would
definitely seem to fit the bill.
>>
>> 2) I think there is still an unresolved issue related to Blog-Sample and
>> how we might be able to demonstrate a bundle upgrade scenario. I'm not
>> sure if this capability is included yet in Blog-Sample - so it might still
>> be a non-issue at the moment. However, we had some discussion on this a
>> week ago or so related to how we might be able to include multiple versions
>> of components in the sample so that an upgrade scenario could be
>> demonstrated. If that is still a goal for the 0.1 release we will need to
>> come up with some solution.
>
> no ideas from me on this one :-)
I had a feeling Zoe was doing something in this area when she created
the blog-persistence_1.0.0 directory but it's empty.
Zoe, with ARIES-199 did you check in the code for the JPA persistence
impl then back it out because it went in over the JDBC one. I was
wondering what your plan for adding in the JPA persistence impl again
- in the blog-persistence_1.0.0 dir perhaps which is empty right now.
I think the Blog sample bundles should not be marked 0.1. The sample
will show how a blog-persistence bundle at version 1.1.0 can be used
to update an .eba that only uses blog-persistence at version 1.0. So
these bundles need to be versioned independently of Aries itself. As
part of the release of the blog sample there should be a .eba artifact
containing the blog bundles including the blog persistence bundle at
version 1.0.0. There should be an artifact that contains the blog
persistence bundle at version 1.1.0 - but that isn't a .eba - it
should probably just be a zip.
So I think the maven-release-plugin needs to pass over the Blog sample
bundles and run on the blog assembly project to create a .eba at
0.1-incubating containing bundles created from the other modules at
version 1.0.0 (no incubating). The Apache release process requires
each released artifact to contain NOTICE, LICENSE and have incubating
in the artifact's name. Which means we can't release the blog sample
bundles directly because they need to be at version 1.0.0 and 1.1.0.
>
> thanks
> david jencks
>
>>
>> Joe
>>
>>
>> David Jencks wrote:
>>>
>>> I think everything is ok.... I think (at least with dryRun=true) that the
>>> release plugin builds the project first as-is and checks that signing etc
>>> works.
>>> I added autoVersionSubmodules=true in the root parent pom which will make
>>> things work more smoothly :-)
>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT first,
>>> I'm happy to do this if you want.
>>> thanks
>>> david jencks
>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>
>>>> scratch that. I'm working thru this:
>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>> there's several steps I haven't done.
>>>>
>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>
>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>>>
>>>>>> I've done most of what I think is needed for aries to be basically
>>>>>> releasable. There are some bits left and possibly stuff I've missed.
>>>>>>
>>>>>> 1. legal file review. There are a bunch of NOTICE files that claim
>>>>>> that
>>>>>> work from osgi is included. Really? license and notice files are
>>>>>> supposed
>>>>>> to apply to what is actually in an artifact or checkout. Are some of
>>>>>> our
>>>>>> source files copied from an osgi source? Also all the legal files
>>>>>> that end
>>>>>> up in binary artifacts need to be checked. Also we need to run the
>>>>>> rat
>>>>>> plugin: this should be configured in the default pom. Not sure if I
>>>>>> will
>>>>>> get to this.
>>>>>>
>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how to
>>>>>> make
>>>>>> sure that an eba is working so I didn't mess with this. I think the
>>>>>> plugin
>>>>>> itself is working well enough to use though.
>>>>>>
>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>> convenient to
>>>>>> have these alphabetized so I can find what I'm looking for, but I
>>>>>> haven't
>>>>>> done this in most poms. I'm not sure why there isn't a usable tool
>>>>>> for
>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>
>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>> dependency:analyze and
>>>>>> look carefully at the results. The results from this can require
>>>>>> interpretation so its best if someone who is very familiar with how
>>>>>> the code
>>>>>> works does this.
>>>>>>
>>>>>> 4. before a release all snapshots need to be resolved to released
>>>>>> versions.
>>>>>> I don't know if there are any snapshots.
>>>>>>
>>>>>> To summarize what I've tried to do:
>>>>>>
>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>> dependencies
>>>>>> that all projects are pretty sure to use including the pax stuff used
>>>>>> mostly
>>>>>> for testing.
>>>>>>
>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>
>>>>>> 3. each subproject has an scm element in its pom, but no others do.
>>>>>>
>>>>>> 4. each subproject has dependency management for everything included
>>>>>> in it.
>>>>>> In addition, it has its subprojects listed in dependency management.
>>>>>> (this
>>>>>> is bent slightly for the samples). This means that
>>>>>> (a) modules in a subproject don't need to include versions for use of
>>>>>> other
>>>>>> modules
>>>>>> (b) you can get dependency management for all the modules in a
>>>>>> subproject
>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>> samples pom
>>>>>> for an example).
>>>>>>
>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>> dependency
>>>>>> elements.
>>>>>>
>>>>>> Release is going to involve...
>>>>>>
>>>>>> releasing the parent
>>>>>
>>>>> In trunk/parent I tried:
>>>>>
>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>
>>>>> Providing 0.1-incubating for the release version
>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development version
>>>>>
>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>
>>>>> [INFO] [INFO]
>>>>> ------------------------------------------------------------------------
>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>> [INFO] [INFO]
>>>>> ------------------------------------------------------------------------
>>>>> [INFO] [INFO] [clean:clean]
>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>> 'false'.
>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added,
>>>>> skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>>>> skipping
>>>>> [INFO] [INFO] Building zip:
>>>>>
>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added,
>>>>> skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>>>> skipping
>>>>> [INFO] [INFO] Preparing source:jar
>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>> recursive invocation.
>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>> classpath-capable package
>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>
>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>
>>>>> Then stops at the gpg stage. I thought it would prompt me for my key
>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>
>>>>>> updating the parent version wherever it is used (all subproject
>>>>>> parents)
>>>>>>
>>>>>> releasing the subprojects in an appropriate order and updating their
>>>>>> versions wherever they are used.
>>>>>>
>>>>>> It might be worthwhile changing the pom version to
>>>>>> 0.1-incubating-SNAPSHOT
>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this
>>>>>> because
>>>>>> then the versions plugin can be used to update use of a subproject to
>>>>>> the
>>>>>> newly released version of what it uses. Going from
>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>
>>>>>> As noted in the "root" pom, don't try to release the root pom and
>>>>>> don't try
>>>>>> release everything at once from the root pom.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>
>>>>>>> I started looking into cleaning up the build, and of course it is
>>>>>>> taking
>>>>>>> longer than I expected.
>>>>>>>
>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>
>>>>>>> There are some projects in application that stop compiling if you
>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are
>>>>>>> getting on
>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions to
>>>>>>> the
>>>>>>> dependencies seems to fix it if you can figure out where the out of
>>>>>>> date
>>>>>>> jars are coming from.
>>>>>>>
>>>>>>> The build is already much closer to a multi-release model than a
>>>>>>> single
>>>>>>> release model.
>>>>>>>
>>>>>>> I've diffed what I have so far and attached it to ARIES-173. It
>>>>>>> includes
>>>>>>> scm info and a lot of version corrections. Due to the failing tests
>>>>>>> I'm not
>>>>>>> too comfortable committing it.
>>>>>>>
>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> It 'd be great if you are willing to fix these build issues, since
>>>>>>>> you
>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>
>>>>>>>> I know the maven release plugin isn't friendly to use some cases, so
>>>>>>>> it is best we get these resolved to make our release process a bit
>>>>>>>> easier.
>>>>>>>>
>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time with the
>>>>>>>> release.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Lin
>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>> <da...@yahoo.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I would like to understand the problems you see better, but I do
>>>>>>>>>> not
>>>>>>>>>> have
>>>>>>>>>> the maven background you guys have, any chance you could explain
>>>>>>>>>> what
>>>>>>>>>> the
>>>>>>>>>> problems are, why they are problems and the solution at some
>>>>>>>>>> point?
>>>>>>>>>
>>>>>>>>> The biggest immediate problem is that without correct svn info you
>>>>>>>>> can't
>>>>>>>>> do
>>>>>>>>> a release with the release plugin. I'm pretty sure the way its set
>>>>>>>>> up
>>>>>>>>> now,
>>>>>>>>> when you try, the tag will be under maven's apache pom, not aries.
>>>>>>>>> (you'll
>>>>>>>>> fail unless you happen to be a maven committer too). You definitely
>>>>>>>>> don't
>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>
>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>> application,
>>>>>>>>> and samples should always be released in synchrony. Any time two
>>>>>>>>> of
>>>>>>>>> them
>>>>>>>>> happen to be ready for release at the same time it will be purely
>>>>>>>>> accidental. Right now everyone wants to get a milestone out the
>>>>>>>>> door,
>>>>>>>>> but
>>>>>>>>> looking at the different projects their state of completion is
>>>>>>>>> pretty
>>>>>>>>> much
>>>>>>>>> wildly different. A decision to release all of them at once is not
>>>>>>>>> based in
>>>>>>>>> any way on them being equally complete. I'm suggesting that since
>>>>>>>>> build
>>>>>>>>> fixes are needed anyway, why not set up a maintainable structure
>>>>>>>>> that
>>>>>>>>> will
>>>>>>>>> continue to work beyond this publicity release. The benefit to
>>>>>>>>> users is
>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>> otherwise
>>>>>>>>> the
>>>>>>>>> entire project will never be in a releasable state at once. (I'm
>>>>>>>>> only
>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>
>>>>>>>>> What got me looking at this at all is what look like wild gyrations
>>>>>>>>> that
>>>>>>>>> don't really use maven properly to get an .eba (or some artifact)
>>>>>>>>> out
>>>>>>>>> the
>>>>>>>>> door. This might be ok for one release but (a) I think this can be
>>>>>>>>> done
>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>> eba-maven-plugin
>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>
>>>>>>>>> I'm willing to fix the build and probably work on an eba plugin,
>>>>>>>>> but
>>>>>>>>> want to
>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Alasdair
>>>>>>>>>>
>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> This discussion got me worried enough to take a look at the aries
>>>>>>>>>>> build.
>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>
>>>>>>>>>>> While it might feel good to try to push out a release as fast as
>>>>>>>>>>> possible
>>>>>>>>>>> I'd prefer to see a sustainable build system in place first. So
>>>>>>>>>>> far
>>>>>>>>>>> it
>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely coupled
>>>>>>>>>>> subprojects. Building them all at once is not going to work for
>>>>>>>>>>> long.
>>>>>>>>>>> I
>>>>>>>>>>> think we should recognize that and put that in the build system
>>>>>>>>>>> now.
>>>>>>>>>>> To me
>>>>>>>>>>> this means:
>>>>>>>>>>>
>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>>>>>>>> (mostly
>>>>>>>>>>> svn info) (right now this is completely missing everywhere as
>>>>>>>>>>> far as
>>>>>>>>>>> I can
>>>>>>>>>>> see, which will result in ares getting tagged into svn as part of
>>>>>>>>>>> the
>>>>>>>>>>> apache
>>>>>>>>>>> pom)
>>>>>>>>>>>
>>>>>>>>>>> We can still have a "fake" pom that builds everything, but it
>>>>>>>>>>> won't be
>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>
>>>>>>>>>>> Having separately released subprojects does not prevent having a
>>>>>>>>>>> single
>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>
>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>>>>>>>
>>>>>>>>>>> In addition relevant to this particular bit of the thread, we
>>>>>>>>>>> need an
>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>>>>>>>> release
>>>>>>>>>>> would
>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>
>>>>>>>>>>> If there's general agreement I can spend some time playing with
>>>>>>>>>>> the
>>>>>>>>>>> build
>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>
>>>>>>>>>>> thoughts?
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'd also like to see us release the sample applications but I
>>>>>>>>>>>>>> think
>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>
>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the
>>>>>>>>>>>>> .eba
>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the artifact
>>>>>>>>>>>>> to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the
>>>>>>>>>>>>> .eba for
>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>
>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you know
>>>>>>>>>>>> if
>>>>>>>>>>>> it
>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>> artifacts
>>>>>>>>>>>> when we do
>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>> mechanism for
>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>
>>>>>>>>>>>>>> I think the result is that the eba will not be available in a
>>>>>>>>>>>>>> maven
>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One of the differences is that AriesTrader first generates a
>>>>>>>>>>>>>> jar
>>>>>>>>>>>>>> using
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>> even
>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred approach
>>>>>>>>>>>>> long
>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from
>>>>>>>>>>>>> maven
>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>
>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work out -
>>>>>>>>>>>> is
>>>>>>>>>>>> there anything wrong with the approach I mentioned earlier of
>>>>>>>>>>>> just
>>>>>>>>>>>> using the
>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>>>>>>>> application
>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>> The transaction component is functional and we've been using
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I was really just interested in the general objectives and
>>>>>>>>>>>>>>>> timing
>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>>>>>>>>> means
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a little
>>>>>>>>>>>>>>>> too
>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>> and planning along the same lines (or understand quickly if
>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> release candidate next week means that we should be getting
>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in or out
>>>>>>>>>>>>>>>> -
>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect not
>>>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am
>>>>>>>>>>>>>>>>> now out
>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So
>>>>>>>>>>>>>>>>> 'must
>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main
>>>>>>>>>>>>>>>>> area of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>> this is the first release there are likely a few unknowns -
>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>>>>>>>>> target a
>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as
>>>>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we would
>>>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must have"
>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> have"), the current status of that content, target dates
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is
>>>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>>
>> --
>> Joe
>
>
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 2 March 2010 17:44, David Jencks <da...@yahoo.com> wrote:
> I think everything is ok.... I think (at least with dryRun=true) that the
> release plugin builds the project first as-is and checks that signing etc
> works.
>
> I added autoVersionSubmodules=true in the root parent pom which will make
> things work more smoothly :-)
If that means the maven-release-plugin won't ask what version number
to use for the child modules of the one being released then this is
good and just what we want for most modules. I think we might need to
do something special with the modules representing the blog sample
bundles (as Joe mentions in another email).
>
> I really recommend changing the version to 0.1-incubating-SNAPSHOT first,
> I'm happy to do this if you want.
I agree, that would give the maven-bundle-plugin less to do and one
less moving part would be fine with me. Thanks.
>
>
> thanks
> david jencks
>
> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>
>> scratch that. I'm working thru this:
>> http://maven.apache.org/developers/release/apache-release.html as
>> there's several steps I haven't done.
>>
>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>
>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>
>>>> I've done most of what I think is needed for aries to be basically
>>>> releasable. There are some bits left and possibly stuff I've missed.
>>>>
>>>> 1. legal file review. There are a bunch of NOTICE files that claim that
>>>> work from osgi is included. Really? license and notice files are
>>>> supposed
>>>> to apply to what is actually in an artifact or checkout. Are some of
>>>> our
>>>> source files copied from an osgi source? Also all the legal files that
>>>> end
>>>> up in binary artifacts need to be checked. Also we need to run the rat
>>>> plugin: this should be configured in the default pom. Not sure if I
>>>> will
>>>> get to this.
>>>>
>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how to
>>>> make
>>>> sure that an eba is working so I didn't mess with this. I think the
>>>> plugin
>>>> itself is working well enough to use though.
>>>>
>>>> 2. ordering dependencies and dependency management. I find it
>>>> convenient to
>>>> have these alphabetized so I can find what I'm looking for, but I
>>>> haven't
>>>> done this in most poms. I'm not sure why there isn't a usable tool for
>>>> doing this but I haven't found one. Dull but useful...
>>>>
>>>> 3. It would probably be a really good idea to run mvn dependency:analyze
>>>> and
>>>> look carefully at the results. The results from this can require
>>>> interpretation so its best if someone who is very familiar with how the
>>>> code
>>>> works does this.
>>>>
>>>> 4. before a release all snapshots need to be resolved to released
>>>> versions.
>>>> I don't know if there are any snapshots.
>>>>
>>>> To summarize what I've tried to do:
>>>>
>>>> 1. default-parent has dependency management for the basic osgi
>>>> dependencies
>>>> that all projects are pretty sure to use including the pax stuff used
>>>> mostly
>>>> for testing.
>>>>
>>>> 2. each subproject has legal files in its checkout root
>>>>
>>>> 3. each subproject has an scm element in its pom, but no others do.
>>>>
>>>> 4. each subproject has dependency management for everything included in
>>>> it.
>>>> In addition, it has its subprojects listed in dependency management.
>>>> (this
>>>> is bent slightly for the samples). This means that
>>>> (a) modules in a subproject don't need to include versions for use of
>>>> other
>>>> modules
>>>> (b) you can get dependency management for all the modules in a
>>>> subproject
>>>> by depending on the subproject pom with scope import. (see the samples
>>>> pom
>>>> for an example).
>>>>
>>>> 5. As a result of (4), modules don't have any versions in any dependency
>>>> elements.
>>>>
>>>> Release is going to involve...
>>>>
>>>> releasing the parent
>>>
>>> In trunk/parent I tried:
>>>
>>> mvn -DdryRun=true release:prepare -Papache-release
>>>
>>> Providing 0.1-incubating for the release version
>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development version
>>>
>>> then when it builds the 'Top Parent POM' it outputs this:
>>>
>>> [INFO] [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>> [INFO] [INFO] task-segment: [clean, verify]
>>> [INFO] [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] [INFO] [clean:clean]
>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound => 'false'.
>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>> [INFO] [INFO] [site:attach-descriptor]
>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added,
>>> skipping
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>> skipping
>>> [INFO] [INFO] Building zip:
>>>
>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added,
>>> skipping
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>> skipping
>>> [INFO] [INFO] Preparing source:jar
>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>> recursive invocation.
>>> [INFO] [INFO] No goals needed for project - skipping
>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>> classpath-capable package
>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>
>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>
>>> Then stops at the gpg stage. I thought it would prompt me for my key
>>> passphrase at this point. Do I need gpg-agent to be running?
>>>
>>>> updating the parent version wherever it is used (all subproject parents)
>>>>
>>>> releasing the subprojects in an appropriate order and updating their
>>>> versions wherever they are used.
>>>>
>>>> It might be worthwhile changing the pom version to
>>>> 0.1-incubating-SNAPSHOT
>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this
>>>> because
>>>> then the versions plugin can be used to update use of a subproject to
>>>> the
>>>> newly released version of what it uses. Going from
>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>
>>>> As noted in the "root" pom, don't try to release the root pom and don't
>>>> try
>>>> release everything at once from the root pom.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>>
>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>
>>>>> I started looking into cleaning up the build, and of course it is
>>>>> taking
>>>>> longer than I expected.
>>>>>
>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>
>>>>> There are some projects in application that stop compiling if you
>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are
>>>>> getting on
>>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions to
>>>>> the
>>>>> dependencies seems to fix it if you can figure out where the out of
>>>>> date
>>>>> jars are coming from.
>>>>>
>>>>> The build is already much closer to a multi-release model than a single
>>>>> release model.
>>>>>
>>>>> I've diffed what I have so far and attached it to ARIES-173. It
>>>>> includes
>>>>> scm info and a lot of version corrections. Due to the failing tests
>>>>> I'm not
>>>>> too comfortable committing it.
>>>>>
>>>>> Is anyone else seeing test failures locally?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> It 'd be great if you are willing to fix these build issues, since you
>>>>>> just went through a big release in Geronimo. :)
>>>>>>
>>>>>> I know the maven release plugin isn't friendly to use some cases, so
>>>>>> it is best we get these resolved to make our release process a bit
>>>>>> easier.
>>>>>>
>>>>>> EBA plugin would be a very nice add-on, if it comes in time with the
>>>>>> release.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Lin
>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <da...@yahoo.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> I would like to understand the problems you see better, but I do not
>>>>>>>> have
>>>>>>>> the maven background you guys have, any chance you could explain
>>>>>>>> what
>>>>>>>> the
>>>>>>>> problems are, why they are problems and the solution at some point?
>>>>>>>
>>>>>>> The biggest immediate problem is that without correct svn info you
>>>>>>> can't
>>>>>>> do
>>>>>>> a release with the release plugin. I'm pretty sure the way its set
>>>>>>> up
>>>>>>> now,
>>>>>>> when you try, the tag will be under maven's apache pom, not aries.
>>>>>>> (you'll
>>>>>>> fail unless you happen to be a maven committer too). You definitely
>>>>>>> don't
>>>>>>> want to try to do a release without the release plugin.
>>>>>>>
>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>> application,
>>>>>>> and samples should always be released in synchrony. Any time two of
>>>>>>> them
>>>>>>> happen to be ready for release at the same time it will be purely
>>>>>>> accidental. Right now everyone wants to get a milestone out the
>>>>>>> door,
>>>>>>> but
>>>>>>> looking at the different projects their state of completion is pretty
>>>>>>> much
>>>>>>> wildly different. A decision to release all of them at once is not
>>>>>>> based in
>>>>>>> any way on them being equally complete. I'm suggesting that since
>>>>>>> build
>>>>>>> fixes are needed anyway, why not set up a maintainable structure that
>>>>>>> will
>>>>>>> continue to work beyond this publicity release. The benefit to users
>>>>>>> is
>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>> otherwise
>>>>>>> the
>>>>>>> entire project will never be in a releasable state at once. (I'm only
>>>>>>> exaggerating a little bit :-)
>>>>>>>
>>>>>>> What got me looking at this at all is what look like wild gyrations
>>>>>>> that
>>>>>>> don't really use maven properly to get an .eba (or some artifact) out
>>>>>>> the
>>>>>>> door. This might be ok for one release but (a) I think this can be
>>>>>>> done
>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>> eba-maven-plugin
>>>>>>> seems like the obvious more long term solution.
>>>>>>>
>>>>>>> I'm willing to fix the build and probably work on an eba plugin, but
>>>>>>> want to
>>>>>>> be sure this is ok with everyone first.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Alasdair
>>>>>>>>
>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> This discussion got me worried enough to take a look at the aries
>>>>>>>>> build.
>>>>>>>>> Now I'm even more worried.
>>>>>>>>>
>>>>>>>>> While it might feel good to try to push out a release as fast as
>>>>>>>>> possible
>>>>>>>>> I'd prefer to see a sustainable build system in place first. So
>>>>>>>>> far
>>>>>>>>> it
>>>>>>>>> looks to me as if aries is going to be a bunch of loosely coupled
>>>>>>>>> subprojects. Building them all at once is not going to work for
>>>>>>>>> long.
>>>>>>>>> I
>>>>>>>>> think we should recognize that and put that in the build system
>>>>>>>>> now.
>>>>>>>>> To me
>>>>>>>>> this means:
>>>>>>>>>
>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>>>>>> (mostly
>>>>>>>>> svn info) (right now this is completely missing everywhere as far
>>>>>>>>> as
>>>>>>>>> I can
>>>>>>>>> see, which will result in ares getting tagged into svn as part of
>>>>>>>>> the
>>>>>>>>> apache
>>>>>>>>> pom)
>>>>>>>>>
>>>>>>>>> We can still have a "fake" pom that builds everything, but it won't
>>>>>>>>> be
>>>>>>>>> part of any release procedure.
>>>>>>>>>
>>>>>>>>> Having separately released subprojects does not prevent having a
>>>>>>>>> single
>>>>>>>>> vote on all the releases.
>>>>>>>>>
>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>>>>>
>>>>>>>>> In addition relevant to this particular bit of the thread, we need
>>>>>>>>> an
>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>>>>>> release
>>>>>>>>> would
>>>>>>>>> be a great idea IMO.
>>>>>>>>>
>>>>>>>>> If there's general agreement I can spend some time playing with the
>>>>>>>>> build
>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>
>>>>>>>>> thoughts?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>
>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'd also like to see us release the sample applications but I
>>>>>>>>>>>> think
>>>>>>>>>>>> there is
>>>>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>>>>>> generate
>>>>>>>>>>>> EBAs
>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>> to
>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>
>>>>>>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>>>>>>> wasn't
>>>>>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>>>>>> pom.xml
>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the
>>>>>>>>>>> .eba
>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the artifact
>>>>>>>>>>> to
>>>>>>>>>>> the
>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba
>>>>>>>>>>> for
>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>
>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you know
>>>>>>>>>> if
>>>>>>>>>> it
>>>>>>>>>> will work with the maven-release-plugin to push the eba artifacts
>>>>>>>>>> when we do
>>>>>>>>>> a release? If so, then I should look at using the same mechanism
>>>>>>>>>> for
>>>>>>>>>> AriesTrader.
>>>>>>>>>>
>>>>>>>>>>>> I think the result is that the eba will not be available in a
>>>>>>>>>>>> maven
>>>>>>>>>>>> repository.
>>>>>>>>>>>>
>>>>>>>>>>>> One of the differences is that AriesTrader first generates a jar
>>>>>>>>>>>> using
>>>>>>>>>>>> the
>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar
>>>>>>>>>>>> will
>>>>>>>>>>>> be
>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>> "application"
>>>>>>>>>>>> even
>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>>>>>> correct
>>>>>>>>>>>> then
>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable approach
>>>>>>>>>>>> for
>>>>>>>>>>>> the 1st
>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>>> assembly
>>>>>>>>>>>> to
>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>>> bundles.
>>>>>>>>>>>
>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred approach
>>>>>>>>>>> long
>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>
>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work out -
>>>>>>>>>> is
>>>>>>>>>> there anything wrong with the approach I mentioned earlier of just
>>>>>>>>>> using the
>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>>>>>> application
>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't think applications are really usable yet and I haven't
>>>>>>>>>>>>> really
>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>> The transaction component is functional and we've been using it
>>>>>>>>>>>>> mostly
>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not talking
>>>>>>>>>>>>> about
>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>>>>>>> better
>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was really just interested in the general objectives and
>>>>>>>>>>>>>> timing
>>>>>>>>>>>>>> since
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>>>>>>> means
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a little
>>>>>>>>>>>>>> too
>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>> and planning along the same lines (or understand quickly if
>>>>>>>>>>>>>> there
>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> release candidate next week means that we should be getting
>>>>>>>>>>>>>> more
>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't have any strong opinions on what should be in or out -
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>> At
>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect not all
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now
>>>>>>>>>>>>>>> out
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get what
>>>>>>>>>>>>>>> we
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main area
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> code deserves at least a README to describe what's possible.
>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>> this is the first release there are likely a few unknowns -
>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we
>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>> Of particular interest would be the content that we would
>>>>>>>>>>>>>>>> like
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must have"
>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> have"), the current status of that content, target dates for
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting to
>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
Thanks David.
After I sent my last note I recalled another place in AriesTrader with
hard-coded versions. The APPLICATION.MF files used for the two EBAs
that are generated includes the bundle version - which is a little
different than the maven version. Where the maven version is currently
1.0.0-incubating-SNAPSHOT the bundle version generated using the
maven-bundle-plugin is 1.0.0.incubating-SNAPSHOT to conform to the OSGi
version scheme.
There are two things which might make this a moot point:
1) If the eba-maven-plugin is enhanced to generate the APPLICATION.MF
then we can use that to resolve the issue.
2) Even though this is an issue with SNAPSHOTs I imagine it isn't an
issue with a non-snapshot release because it won't container the "-XXX"
qualification.
Optionally, I could also just omit the APPLICATION.MF altogether from
the AriesTrader EBAs since I understand that it is not required. That
might be quickest fix for now.
Joe
David Jencks wrote:
>
> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>
>> I agree that we should make a global change to 0.1-incubating-SNAPSHOT
>> first. Why wouldn't we just do that now?
>
> I started doing some experiments here...
>
> running
> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>
> in root and parent upgrades everything maven knows about just fine.
> However there's (1) mentioned below and also a hardcoded version in two
> blueprint-itests.
>
> According to
>
> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>
> we should be able to replace the hardcoded versions with
> .versionAsInProject()
>
> if we run the maven-paxexam-plugin on the project. However I can't get
> it to work yet.
>>
>> Just a heads-up on some other issues related to versions in samples.
>> There are two potential problems that I am aware of:
>>
>> 1) For both Blog-Sample and AriesTrader there are hard-coded version
>> references in the Equinox assembly config.ini file which are used to
>> specify the bundle jars that are to be started for the assembly.
>> Naturally, the versions of the aries bundles in this file won't be
>> updated by the maven-release-plugin. I'm not sure of a good solution
>> for this beyond just manually changing the config.ini files prior to
>> creating a release candidate.
>
> I think we might be able to work around this by putting the config.ini
> files in src/main/resources/filtered-resources and defining a bunch of
> properties in an appropriate pom and using them for the version imports
> of the aries subproject dependencyManagement imports in the samples root
> pom. I haven't tried this yet...
>
>>
>> 2) I think there is still an unresolved issue related to Blog-Sample
>> and how we might be able to demonstrate a bundle upgrade scenario.
>> I'm not sure if this capability is included yet in Blog-Sample - so it
>> might still be a non-issue at the moment. However, we had some
>> discussion on this a week ago or so related to how we might be able to
>> include multiple versions of components in the sample so that an
>> upgrade scenario could be demonstrated. If that is still a goal for
>> the 0.1 release we will need to come up with some solution.
>
> no ideas from me on this one :-)
>
> thanks
> david jencks
>
>>
>> Joe
>>
>>
>> David Jencks wrote:
>>> I think everything is ok.... I think (at least with dryRun=true) that
>>> the release plugin builds the project first as-is and checks that
>>> signing etc works.
>>> I added autoVersionSubmodules=true in the root parent pom which will
>>> make things work more smoothly :-)
>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>>> first, I'm happy to do this if you want.
>>> thanks
>>> david jencks
>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>> scratch that. I'm working thru this:
>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>> there's several steps I haven't done.
>>>>
>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>>> I've done most of what I think is needed for aries to be basically
>>>>>> releasable. There are some bits left and possibly stuff I've missed.
>>>>>>
>>>>>> 1. legal file review. There are a bunch of NOTICE files that
>>>>>> claim that
>>>>>> work from osgi is included. Really? license and notice files are
>>>>>> supposed
>>>>>> to apply to what is actually in an artifact or checkout. Are some
>>>>>> of our
>>>>>> source files copied from an osgi source? Also all the legal files
>>>>>> that end
>>>>>> up in binary artifacts need to be checked. Also we need to run
>>>>>> the rat
>>>>>> plugin: this should be configured in the default pom. Not sure if
>>>>>> I will
>>>>>> get to this.
>>>>>>
>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how
>>>>>> to make
>>>>>> sure that an eba is working so I didn't mess with this. I think
>>>>>> the plugin
>>>>>> itself is working well enough to use though.
>>>>>>
>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>> convenient to
>>>>>> have these alphabetized so I can find what I'm looking for, but I
>>>>>> haven't
>>>>>> done this in most poms. I'm not sure why there isn't a usable
>>>>>> tool for
>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>
>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>> dependency:analyze and
>>>>>> look carefully at the results. The results from this can require
>>>>>> interpretation so its best if someone who is very familiar with
>>>>>> how the code
>>>>>> works does this.
>>>>>>
>>>>>> 4. before a release all snapshots need to be resolved to released
>>>>>> versions.
>>>>>> I don't know if there are any snapshots.
>>>>>>
>>>>>> To summarize what I've tried to do:
>>>>>>
>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>> dependencies
>>>>>> that all projects are pretty sure to use including the pax stuff
>>>>>> used mostly
>>>>>> for testing.
>>>>>>
>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>
>>>>>> 3. each subproject has an scm element in its pom, but no others do.
>>>>>>
>>>>>> 4. each subproject has dependency management for everything
>>>>>> included in it.
>>>>>> In addition, it has its subprojects listed in dependency
>>>>>> management. (this
>>>>>> is bent slightly for the samples). This means that
>>>>>> (a) modules in a subproject don't need to include versions for use
>>>>>> of other
>>>>>> modules
>>>>>> (b) you can get dependency management for all the modules in a
>>>>>> subproject
>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>> samples pom
>>>>>> for an example).
>>>>>>
>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>> dependency
>>>>>> elements.
>>>>>>
>>>>>> Release is going to involve...
>>>>>>
>>>>>> releasing the parent
>>>>>
>>>>> In trunk/parent I tried:
>>>>>
>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>
>>>>> Providing 0.1-incubating for the release version
>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development version
>>>>>
>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>
>>>>> [INFO] [INFO]
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>> [INFO] [INFO]
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>> [INFO] [INFO] [clean:clean]
>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>> 'false'.
>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>> skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>> added, skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>> added, skipping
>>>>> [INFO] [INFO] Building zip:
>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>> skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>> added, skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>> added, skipping
>>>>> [INFO] [INFO] Preparing source:jar
>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>> recursive invocation.
>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>> classpath-capable package
>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>
>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>
>>>>> Then stops at the gpg stage. I thought it would prompt me for my key
>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>
>>>>>> updating the parent version wherever it is used (all subproject
>>>>>> parents)
>>>>>>
>>>>>> releasing the subprojects in an appropriate order and updating their
>>>>>> versions wherever they are used.
>>>>>>
>>>>>> It might be worthwhile changing the pom version to
>>>>>> 0.1-incubating-SNAPSHOT
>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this
>>>>>> because
>>>>>> then the versions plugin can be used to update use of a subproject
>>>>>> to the
>>>>>> newly released version of what it uses. Going from
>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>
>>>>>> As noted in the "root" pom, don't try to release the root pom and
>>>>>> don't try
>>>>>> release everything at once from the root pom.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>
>>>>>>> I started looking into cleaning up the build, and of course it is
>>>>>>> taking
>>>>>>> longer than I expected.
>>>>>>>
>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>
>>>>>>> There are some projects in application that stop compiling if you
>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are
>>>>>>> getting on
>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions
>>>>>>> to the
>>>>>>> dependencies seems to fix it if you can figure out where the out
>>>>>>> of date
>>>>>>> jars are coming from.
>>>>>>>
>>>>>>> The build is already much closer to a multi-release model than a
>>>>>>> single
>>>>>>> release model.
>>>>>>>
>>>>>>> I've diffed what I have so far and attached it to ARIES-173. It
>>>>>>> includes
>>>>>>> scm info and a lot of version corrections. Due to the failing
>>>>>>> tests I'm not
>>>>>>> too comfortable committing it.
>>>>>>>
>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> It 'd be great if you are willing to fix these build issues,
>>>>>>>> since you
>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>
>>>>>>>> I know the maven release plugin isn't friendly to use some
>>>>>>>> cases, so
>>>>>>>> it is best we get these resolved to make our release process a bit
>>>>>>>> easier.
>>>>>>>>
>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time with
>>>>>>>> the
>>>>>>>> release.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Lin
>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>> <da...@yahoo.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I would like to understand the problems you see better, but I
>>>>>>>>>> do not
>>>>>>>>>> have
>>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>>> explain what
>>>>>>>>>> the
>>>>>>>>>> problems are, why they are problems and the solution at some
>>>>>>>>>> point?
>>>>>>>>>
>>>>>>>>> The biggest immediate problem is that without correct svn info
>>>>>>>>> you can't
>>>>>>>>> do
>>>>>>>>> a release with the release plugin. I'm pretty sure the way its
>>>>>>>>> set up
>>>>>>>>> now,
>>>>>>>>> when you try, the tag will be under maven's apache pom, not aries.
>>>>>>>>> (you'll
>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>> definitely
>>>>>>>>> don't
>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>
>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>> application,
>>>>>>>>> and samples should always be released in synchrony. Any time
>>>>>>>>> two of
>>>>>>>>> them
>>>>>>>>> happen to be ready for release at the same time it will be purely
>>>>>>>>> accidental. Right now everyone wants to get a milestone out
>>>>>>>>> the door,
>>>>>>>>> but
>>>>>>>>> looking at the different projects their state of completion is
>>>>>>>>> pretty
>>>>>>>>> much
>>>>>>>>> wildly different. A decision to release all of them at once is
>>>>>>>>> not
>>>>>>>>> based in
>>>>>>>>> any way on them being equally complete. I'm suggesting that
>>>>>>>>> since build
>>>>>>>>> fixes are needed anyway, why not set up a maintainable
>>>>>>>>> structure that
>>>>>>>>> will
>>>>>>>>> continue to work beyond this publicity release. The benefit to
>>>>>>>>> users is
>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>> otherwise
>>>>>>>>> the
>>>>>>>>> entire project will never be in a releasable state at once.
>>>>>>>>> (I'm only
>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>
>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>> gyrations that
>>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>>> artifact) out
>>>>>>>>> the
>>>>>>>>> door. This might be ok for one release but (a) I think this
>>>>>>>>> can be done
>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>> eba-maven-plugin
>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>
>>>>>>>>> I'm willing to fix the build and probably work on an eba
>>>>>>>>> plugin, but
>>>>>>>>> want to
>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Alasdair
>>>>>>>>>>
>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks
>>>>>>>>>> <da...@yahoo.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> This discussion got me worried enough to take a look at the
>>>>>>>>>>> aries
>>>>>>>>>>> build.
>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>
>>>>>>>>>>> While it might feel good to try to push out a release as fast as
>>>>>>>>>>> possible
>>>>>>>>>>> I'd prefer to see a sustainable build system in place first.
>>>>>>>>>>> So far
>>>>>>>>>>> it
>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>> coupled
>>>>>>>>>>> subprojects. Building them all at once is not going to work
>>>>>>>>>>> for long.
>>>>>>>>>>> I
>>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>>> system now.
>>>>>>>>>>> To me
>>>>>>>>>>> this means:
>>>>>>>>>>>
>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>>>>>>>> (mostly
>>>>>>>>>>> svn info) (right now this is completely missing everywhere
>>>>>>>>>>> as far as
>>>>>>>>>>> I can
>>>>>>>>>>> see, which will result in ares getting tagged into svn as
>>>>>>>>>>> part of the
>>>>>>>>>>> apache
>>>>>>>>>>> pom)
>>>>>>>>>>>
>>>>>>>>>>> We can still have a "fake" pom that builds everything, but it
>>>>>>>>>>> won't be
>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>
>>>>>>>>>>> Having separately released subprojects does not prevent having a
>>>>>>>>>>> single
>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>
>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>>>>>>>
>>>>>>>>>>> In addition relevant to this particular bit of the thread, we
>>>>>>>>>>> need an
>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>>>>>>>> release
>>>>>>>>>>> would
>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>
>>>>>>>>>>> If there's general agreement I can spend some time playing
>>>>>>>>>>> with the
>>>>>>>>>>> build
>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>
>>>>>>>>>>> thoughts?
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'd also like to see us release the sample applications
>>>>>>>>>>>>>> but I think
>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>
>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create
>>>>>>>>>>>>> the .eba
>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the
>>>>>>>>>>>>> .eba for
>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>
>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you
>>>>>>>>>>>> know if
>>>>>>>>>>>> it
>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>> artifacts
>>>>>>>>>>>> when we do
>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>> mechanism for
>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>
>>>>>>>>>>>>>> I think the result is that the eba will not be available
>>>>>>>>>>>>>> in a maven
>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One of the differences is that AriesTrader first generates
>>>>>>>>>>>>>> a jar
>>>>>>>>>>>>>> using
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The
>>>>>>>>>>>>>> jar will
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>> even
>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>>>>>>>> correct
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>>> approach long
>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from
>>>>>>>>>>>>> maven
>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>
>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work
>>>>>>>>>>>> out - is
>>>>>>>>>>>> there anything wrong with the approach I mentioned earlier
>>>>>>>>>>>> of just
>>>>>>>>>>>> using the
>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>>>>>>>> application
>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>> The transaction component is functional and we've been
>>>>>>>>>>>>>>> using it
>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn
>>>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ...
>>>>>>>>>>>>>>>> and for
>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>>>>>>>>> better
>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I was really just interested in the general objectives
>>>>>>>>>>>>>>>> and timing
>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in
>>>>>>>>>>>>>>>> Feb means
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>>>> little too
>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>> and planning along the same lines (or understand quickly
>>>>>>>>>>>>>>>> if there
>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>>> getting more
>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in or
>>>>>>>>>>>>>>>> out -
>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect
>>>>>>>>>>>>>>>> not all of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but
>>>>>>>>>>>>>>>>> am now out
>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So
>>>>>>>>>>>>>>>>> 'must
>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each
>>>>>>>>>>>>>>>>> main area of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>>> unknowns -
>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in
>>>>>>>>>>>>>>>>> feb. If
>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to
>>>>>>>>>>>>>>>>> 0.1 and
>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>>>>>>>>> target a
>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated
>>>>>>>>>>>>>>>>>> as we
>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we
>>>>>>>>>>>>>>>>>> would like
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>>>>> dates for
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>>> interesting to
>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release
>>>>>>>>>>>>>>>>>>>>>> as an
>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release
>>>>>>>>>>>>>>>>>>>>>> is an
>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>>
>> --
>> Joe
>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by zoe slattery <zo...@googlemail.com>.
David Jencks wrote:
> I changed the versions to 0.1-incubating-SNAPSHOT (except for some
> blog-sample, see below) and filtered the config.ini files.
>
> I'm still seeing some test failures in jpa-container-itests. I can't
> figure out how these work or why they do or don't fail, I'm hoping
> someone who does can figure out what's wrong.
>
> The blog sample had been changed to use release versions.
Yes - I am still working on getting the JPA persistence implementation
to behave correctly.
> This is not OK for anything that might possibly ever be released. I
> changed them back to 0.1-incubating-SNAPSHOT and the 1.1.0 to
> 0.1.0.1-incubating-SNAPSHOT.
I'll try this, however I'd rather get the the sample working first. If
it doesn't work it shouldn't be part of a release and the discussion
about versions will be immaterial :-)
> If the idea is to show how a version upgrade can install a new feature
> I'd expect the new versions to work and to be consistent with any
> likely versions used in the future. I'm not entirely sure what osgi
> version 0.1.0.1-incubating will turn into, hopefully something
> plausible and larger than 0.1-incubating.
>
> If this is not ok for the purposes of the sample and you really need
> something like 1.0.0 and 1.1.0 then we'll have to find a way so that
> this project can be built but never released.
I don't think we do need that. I did it for my convenience whilst
debugging a bigger issue.
> I think that it is possible to configure deployment to a repository
> under samples/blog-sample/target which would work for this purpose.
> However this is unusual and I hope we can avoid it.
>
> Is anyone planning to convert the eba generation to using the new plugin?
I believe so. At the very least the eba generation will move out of the
blog assembly project.
>
> thanks
> david jencks
>
> On Mar 3, 2010, at 11:00 PM, David Jencks wrote:
>
>>
>> On Mar 2, 2010, at 11:06 AM, David Jencks wrote:
>>
>>>
>>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>>>
>>>> I agree that we should make a global change to
>>>> 0.1-incubating-SNAPSHOT first. Why wouldn't we just do that now?
>>>
>>> I started doing some experiments here...
>>>
>>> running
>>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>>>
>>> in root and parent upgrades everything maven knows about just fine.
>>> However there's (1) mentioned below and also a hardcoded version in
>>> two blueprint-itests.
>>>
>>> According to
>>>
>>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>>>
>>> we should be able to replace the hardcoded versions with
>>> .versionAsInProject()
>>>
>>> if we run the maven-paxexam-plugin on the project. However I can't
>>> get it to work yet.
>>
>> I eventually figured enough about how pax-exam works to fix this. I
>> (hopefully temporarily) borrowed some test code from pax exam and
>> entered a patch at http://issues.ops4j.org/browse/PAXEXAM-171. If
>> there are no better ideas or objections I expect to commit it in a
>> few days. I'd guess at this point people might rather wait till
>> after an aries release or pax-exam release, whichever comes first, to
>> move to using the code once it gets in pax-exam?
>>
>>
>> I'm seeing a bunch of test failures later on with the changed
>> version. If I can't figure out what is causing them reasonably
>> quickly I'm going to commit the version change and suggest that
>> someone who understands how the tests work make them
>> version-independent.
>>
>>
>>>>
>>>> Just a heads-up on some other issues related to versions in
>>>> samples. There are two potential problems that I am aware of:
>>>>
>>>> 1) For both Blog-Sample and AriesTrader there are hard-coded
>>>> version references in the Equinox assembly config.ini file which
>>>> are used to specify the bundle jars that are to be started for the
>>>> assembly. Naturally, the versions of the aries bundles in this file
>>>> won't be updated by the maven-release-plugin. I'm not sure of a
>>>> good solution for this beyond just manually changing the config.ini
>>>> files prior to creating a release candidate.
>>>
>>> I think we might be able to work around this by putting the
>>> config.ini files in src/main/resources/filtered-resources and
>>> defining a bunch of properties in an appropriate pom and using them
>>> for the version imports of the aries subproject dependencyManagement
>>> imports in the samples root pom. I haven't tried this yet...
>>>
>>
>> I think I can do this bit fairly soon...
>>
>> thanks
>> david jencks
>>
>>
>>>>
>>>> 2) I think there is still an unresolved issue related to
>>>> Blog-Sample and how we might be able to demonstrate a bundle
>>>> upgrade scenario. I'm not sure if this capability is included yet
>>>> in Blog-Sample - so it might still be a non-issue at the moment.
>>>> However, we had some discussion on this a week ago or so related to
>>>> how we might be able to include multiple versions of components in
>>>> the sample so that an upgrade scenario could be demonstrated. If
>>>> that is still a goal for the 0.1 release we will need to come up
>>>> with some solution.
>>>
>>> no ideas from me on this one :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Joe
>>>>
>>>>
>>>> David Jencks wrote:
>>>>> I think everything is ok.... I think (at least with dryRun=true)
>>>>> that the release plugin builds the project first as-is and checks
>>>>> that signing etc works.
>>>>> I added autoVersionSubmodules=true in the root parent pom which
>>>>> will make things work more smoothly :-)
>>>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>>>>> first, I'm happy to do this if you want.
>>>>> thanks
>>>>> david jencks
>>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>>> scratch that. I'm working thru this:
>>>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>>>> there's several steps I haven't done.
>>>>>>
>>>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>>>>> I've done most of what I think is needed for aries to be basically
>>>>>>>> releasable. There are some bits left and possibly stuff I've
>>>>>>>> missed.
>>>>>>>>
>>>>>>>> 1. legal file review. There are a bunch of NOTICE files that
>>>>>>>> claim that
>>>>>>>> work from osgi is included. Really? license and notice files
>>>>>>>> are supposed
>>>>>>>> to apply to what is actually in an artifact or checkout. Are
>>>>>>>> some of our
>>>>>>>> source files copied from an osgi source? Also all the legal
>>>>>>>> files that end
>>>>>>>> up in binary artifacts need to be checked. Also we need to run
>>>>>>>> the rat
>>>>>>>> plugin: this should be configured in the default pom. Not sure
>>>>>>>> if I will
>>>>>>>> get to this.
>>>>>>>>
>>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure
>>>>>>>> how to make
>>>>>>>> sure that an eba is working so I didn't mess with this. I
>>>>>>>> think the plugin
>>>>>>>> itself is working well enough to use though.
>>>>>>>>
>>>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>>>> convenient to
>>>>>>>> have these alphabetized so I can find what I'm looking for, but
>>>>>>>> I haven't
>>>>>>>> done this in most poms. I'm not sure why there isn't a usable
>>>>>>>> tool for
>>>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>>>
>>>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>>>> dependency:analyze and
>>>>>>>> look carefully at the results. The results from this can require
>>>>>>>> interpretation so its best if someone who is very familiar with
>>>>>>>> how the code
>>>>>>>> works does this.
>>>>>>>>
>>>>>>>> 4. before a release all snapshots need to be resolved to
>>>>>>>> released versions.
>>>>>>>> I don't know if there are any snapshots.
>>>>>>>>
>>>>>>>> To summarize what I've tried to do:
>>>>>>>>
>>>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>>>> dependencies
>>>>>>>> that all projects are pretty sure to use including the pax
>>>>>>>> stuff used mostly
>>>>>>>> for testing.
>>>>>>>>
>>>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>>>
>>>>>>>> 3. each subproject has an scm element in its pom, but no others
>>>>>>>> do.
>>>>>>>>
>>>>>>>> 4. each subproject has dependency management for everything
>>>>>>>> included in it.
>>>>>>>> In addition, it has its subprojects listed in dependency
>>>>>>>> management. (this
>>>>>>>> is bent slightly for the samples). This means that
>>>>>>>> (a) modules in a subproject don't need to include versions for
>>>>>>>> use of other
>>>>>>>> modules
>>>>>>>> (b) you can get dependency management for all the modules in a
>>>>>>>> subproject
>>>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>>>> samples pom
>>>>>>>> for an example).
>>>>>>>>
>>>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>>>> dependency
>>>>>>>> elements.
>>>>>>>>
>>>>>>>> Release is going to involve...
>>>>>>>>
>>>>>>>> releasing the parent
>>>>>>>
>>>>>>> In trunk/parent I tried:
>>>>>>>
>>>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>>>
>>>>>>> Providing 0.1-incubating for the release version
>>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development
>>>>>>> version
>>>>>>>
>>>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>>>
>>>>>>> [INFO] [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>>>> [INFO] [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> [INFO] [INFO] [clean:clean]
>>>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>>>> 'false'.
>>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>>>> [INFO] [INFO] [assembly:single {execution:
>>>>>>> source-release-assembly}]
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] Building zip:
>>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>>>
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] Preparing source:jar
>>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>>>> recursive invocation.
>>>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>>>> classpath-capable package
>>>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>>>
>>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>>>
>>>>>>> Then stops at the gpg stage. I thought it would prompt me for my
>>>>>>> key
>>>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>>>
>>>>>>>> updating the parent version wherever it is used (all subproject
>>>>>>>> parents)
>>>>>>>>
>>>>>>>> releasing the subprojects in an appropriate order and updating
>>>>>>>> their
>>>>>>>> versions wherever they are used.
>>>>>>>>
>>>>>>>> It might be worthwhile changing the pom version to
>>>>>>>> 0.1-incubating-SNAPSHOT
>>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing
>>>>>>>> this because
>>>>>>>> then the versions plugin can be used to update use of a
>>>>>>>> subproject to the
>>>>>>>> newly released version of what it uses. Going from
>>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>>>
>>>>>>>> As noted in the "root" pom, don't try to release the root pom
>>>>>>>> and don't try
>>>>>>>> release everything at once from the root pom.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> I started looking into cleaning up the build, and of course it
>>>>>>>>> is taking
>>>>>>>>> longer than I expected.
>>>>>>>>>
>>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>>>
>>>>>>>>> There are some projects in application that stop compiling if you
>>>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts
>>>>>>>>> are getting on
>>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding
>>>>>>>>> exclusions to the
>>>>>>>>> dependencies seems to fix it if you can figure out where the
>>>>>>>>> out of date
>>>>>>>>> jars are coming from.
>>>>>>>>>
>>>>>>>>> The build is already much closer to a multi-release model than
>>>>>>>>> a single
>>>>>>>>> release model.
>>>>>>>>>
>>>>>>>>> I've diffed what I have so far and attached it to ARIES-173.
>>>>>>>>> It includes
>>>>>>>>> scm info and a lot of version corrections. Due to the failing
>>>>>>>>> tests I'm not
>>>>>>>>> too comfortable committing it.
>>>>>>>>>
>>>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> It 'd be great if you are willing to fix these build issues,
>>>>>>>>>> since you
>>>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>>>
>>>>>>>>>> I know the maven release plugin isn't friendly to use some
>>>>>>>>>> cases, so
>>>>>>>>>> it is best we get these resolved to make our release process
>>>>>>>>>> a bit
>>>>>>>>>> easier.
>>>>>>>>>>
>>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time
>>>>>>>>>> with the
>>>>>>>>>> release.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Lin
>>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>>>> <da...@yahoo.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I would like to understand the problems you see better, but
>>>>>>>>>>>> I do not
>>>>>>>>>>>> have
>>>>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>>>>> explain what
>>>>>>>>>>>> the
>>>>>>>>>>>> problems are, why they are problems and the solution at
>>>>>>>>>>>> some point?
>>>>>>>>>>>
>>>>>>>>>>> The biggest immediate problem is that without correct svn
>>>>>>>>>>> info you can't
>>>>>>>>>>> do
>>>>>>>>>>> a release with the release plugin. I'm pretty sure the way
>>>>>>>>>>> its set up
>>>>>>>>>>> now,
>>>>>>>>>>> when you try, the tag will be under maven's apache pom, not
>>>>>>>>>>> aries.
>>>>>>>>>>> (you'll
>>>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>>>> definitely
>>>>>>>>>>> don't
>>>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>>>
>>>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>>>> application,
>>>>>>>>>>> and samples should always be released in synchrony. Any
>>>>>>>>>>> time two of
>>>>>>>>>>> them
>>>>>>>>>>> happen to be ready for release at the same time it will be
>>>>>>>>>>> purely
>>>>>>>>>>> accidental. Right now everyone wants to get a milestone out
>>>>>>>>>>> the door,
>>>>>>>>>>> but
>>>>>>>>>>> looking at the different projects their state of completion
>>>>>>>>>>> is pretty
>>>>>>>>>>> much
>>>>>>>>>>> wildly different. A decision to release all of them at once
>>>>>>>>>>> is not
>>>>>>>>>>> based in
>>>>>>>>>>> any way on them being equally complete. I'm suggesting that
>>>>>>>>>>> since build
>>>>>>>>>>> fixes are needed anyway, why not set up a maintainable
>>>>>>>>>>> structure that
>>>>>>>>>>> will
>>>>>>>>>>> continue to work beyond this publicity release. The benefit
>>>>>>>>>>> to users is
>>>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>>>> otherwise
>>>>>>>>>>> the
>>>>>>>>>>> entire project will never be in a releasable state at once.
>>>>>>>>>>> (I'm only
>>>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>>>
>>>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>>>> gyrations that
>>>>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>>>>> artifact) out
>>>>>>>>>>> the
>>>>>>>>>>> door. This might be ok for one release but (a) I think this
>>>>>>>>>>> can be done
>>>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>>>> eba-maven-plugin
>>>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>>>
>>>>>>>>>>> I'm willing to fix the build and probably work on an eba
>>>>>>>>>>> plugin, but
>>>>>>>>>>> want to
>>>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Alasdair
>>>>>>>>>>>>
>>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks
>>>>>>>>>>>> <da...@yahoo.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> This discussion got me worried enough to take a look at
>>>>>>>>>>>>> the aries
>>>>>>>>>>>>> build.
>>>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>>>
>>>>>>>>>>>>> While it might feel good to try to push out a release as
>>>>>>>>>>>>> fast as
>>>>>>>>>>>>> possible
>>>>>>>>>>>>> I'd prefer to see a sustainable build system in place
>>>>>>>>>>>>> first. So far
>>>>>>>>>>>>> it
>>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>>>> coupled
>>>>>>>>>>>>> subprojects. Building them all at once is not going to
>>>>>>>>>>>>> work for long.
>>>>>>>>>>>>> I
>>>>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>>>>> system now.
>>>>>>>>>>>>> To me
>>>>>>>>>>>>> this means:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>>>>>>> released
>>>>>>>>>>>>> (mostly
>>>>>>>>>>>>> svn info) (right now this is completely missing
>>>>>>>>>>>>> everywhere as far as
>>>>>>>>>>>>> I can
>>>>>>>>>>>>> see, which will result in ares getting tagged into svn as
>>>>>>>>>>>>> part of the
>>>>>>>>>>>>> apache
>>>>>>>>>>>>> pom)
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can still have a "fake" pom that builds everything, but
>>>>>>>>>>>>> it won't be
>>>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Having separately released subprojects does not prevent
>>>>>>>>>>>>> having a
>>>>>>>>>>>>> single
>>>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources
>>>>>>>>>>>>> and
>>>>>>>>>>>>> filtered-resources to distinguish when filtering is called
>>>>>>>>>>>>> for.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In addition relevant to this particular bit of the thread,
>>>>>>>>>>>>> we need an
>>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a
>>>>>>>>>>>>> first release
>>>>>>>>>>>>> would
>>>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If there's general agreement I can spend some time playing
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> build
>>>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thoughts?
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd also like to see us release the sample applications
>>>>>>>>>>>>>>>> but I think
>>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and
>>>>>>>>>>>>>>>> AriesTrader
>>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly
>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>>> being pushed into my local repo. I've made some changes
>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to
>>>>>>>>>>>>>>> create the .eba
>>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>>>>>>>>>>> the .eba for
>>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do
>>>>>>>>>>>>>> you know if
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>>> when we do
>>>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>>>> mechanism for
>>>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think the result is that the eba will not be
>>>>>>>>>>>>>>>> available in a maven
>>>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One of the differences is that AriesTrader first
>>>>>>>>>>>>>>>> generates a jar
>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba.
>>>>>>>>>>>>>>>> The jar will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that
>>>>>>>>>>>>>>>> is correct
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my
>>>>>>>>>>>>>>>> equinox
>>>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the
>>>>>>>>>>>>>>>> individual
>>>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>>>>> approach long
>>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact
>>>>>>>>>>>>>>> from maven
>>>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't
>>>>>>>>>>>>>> work out - is
>>>>>>>>>>>>>> there anything wrong with the approach I mentioned
>>>>>>>>>>>>>> earlier of just
>>>>>>>>>>>>>> using the
>>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the
>>>>>>>>>>>>>> current
>>>>>>>>>>>>>> application
>>>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>>>> The transaction component is functional and we've been
>>>>>>>>>>>>>>>>> using it
>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn
>>>>>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ...
>>>>>>>>>>>>>>>>>> and for
>>>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me
>>>>>>>>>>>>>>>>>> get a better
>>>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I was really just interested in the general
>>>>>>>>>>>>>>>>>> objectives and timing
>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in
>>>>>>>>>>>>>>>>>> Feb means
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>>>>>> little too
>>>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The more communication the better. It's important to
>>>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>>> and planning along the same lines (or understand
>>>>>>>>>>>>>>>>>> quickly if there
>>>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are
>>>>>>>>>>>>>>>>>> thinking of
>>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>>>>> getting more
>>>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in
>>>>>>>>>>>>>>>>>> or out -
>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> general it doesn't make sense to release things that
>>>>>>>>>>>>>>>>>> aren't
>>>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I
>>>>>>>>>>>>>>>>>> suspect not all of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday
>>>>>>>>>>>>>>>>>>> but am now out
>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to
>>>>>>>>>>>>>>>>>>> get what we
>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires.
>>>>>>>>>>>>>>>>>>> So 'must
>>>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each
>>>>>>>>>>>>>>>>>>> main area of
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>>>>> unknowns -
>>>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in
>>>>>>>>>>>>>>>>>>> feb. If
>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0
>>>>>>>>>>>>>>>>>>> to 0.1 and
>>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1
>>>>>>>>>>>>>>>>>>> to target a
>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn
>>>>>>>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding
>>>>>>>>>>>>>>>>>>>> the release
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize
>>>>>>>>>>>>>>>>>>>> your thoughts
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep
>>>>>>>>>>>>>>>>>>>> updated as we
>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we
>>>>>>>>>>>>>>>>>>>> would like
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider
>>>>>>>>>>>>>>>>>>>> "must have" from
>>>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>>>>>>> dates for
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any
>>>>>>>>>>>>>>>>>>>>>> help.
>>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>>>>> interesting to
>>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one
>>>>>>>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release
>>>>>>>>>>>>>>>>>>>>>>> manager.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with
>>>>>>>>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint
>>>>>>>>>>>>>>>>>>>>>>>> release as an
>>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache
>>>>>>>>>>>>>>>>>>>>>>>> release is an
>>>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see
>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>> --
>>>> Joe
>>>
>>
>
>
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
David Jencks wrote:
> I changed the versions to 0.1-incubating-SNAPSHOT (except for some
> blog-sample, see below) and filtered the config.ini files.
>
> I'm still seeing some test failures in jpa-container-itests. I can't
> figure out how these work or why they do or don't fail, I'm hoping
> someone who does can figure out what's wrong.
>
> The blog sample had been changed to use release versions. This is not
> OK for anything that might possibly ever be released. I changed them
> back to 0.1-incubating-SNAPSHOT and the 1.1.0 to
> 0.1.0.1-incubating-SNAPSHOT. If the idea is to show how a version
> upgrade can install a new feature I'd expect the new versions to work
> and to be consistent with any likely versions used in the future. I'm
> not entirely sure what osgi version 0.1.0.1-incubating will turn into,
> hopefully something plausible and larger than 0.1-incubating.
>
> If this is not ok for the purposes of the sample and you really need
> something like 1.0.0 and 1.1.0 then we'll have to find a way so that
> this project can be built but never released. I think that it is
> possible to configure deployment to a repository under
> samples/blog-sample/target which would work for this purpose. However
> this is unusual and I hope we can avoid it.
>
> Is anyone planning to convert the eba generation to using the new plugin?
I'll update AriesTrader for the eba generation using the new plugin today.
Thanks,
Joe
>
> thanks
> david jencks
>
> On Mar 3, 2010, at 11:00 PM, David Jencks wrote:
>
>>
>> On Mar 2, 2010, at 11:06 AM, David Jencks wrote:
>>
>>>
>>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>>>
>>>> I agree that we should make a global change to
>>>> 0.1-incubating-SNAPSHOT first. Why wouldn't we just do that now?
>>>
>>> I started doing some experiments here...
>>>
>>> running
>>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>>>
>>> in root and parent upgrades everything maven knows about just fine.
>>> However there's (1) mentioned below and also a hardcoded version in
>>> two blueprint-itests.
>>>
>>> According to
>>>
>>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>>>
>>> we should be able to replace the hardcoded versions with
>>> .versionAsInProject()
>>>
>>> if we run the maven-paxexam-plugin on the project. However I can't
>>> get it to work yet.
>>
>> I eventually figured enough about how pax-exam works to fix this. I
>> (hopefully temporarily) borrowed some test code from pax exam and
>> entered a patch at http://issues.ops4j.org/browse/PAXEXAM-171. If
>> there are no better ideas or objections I expect to commit it in a few
>> days. I'd guess at this point people might rather wait till after an
>> aries release or pax-exam release, whichever comes first, to move to
>> using the code once it gets in pax-exam?
>>
>>
>> I'm seeing a bunch of test failures later on with the changed
>> version. If I can't figure out what is causing them reasonably
>> quickly I'm going to commit the version change and suggest that
>> someone who understands how the tests work make them version-independent.
>>
>>
>>>>
>>>> Just a heads-up on some other issues related to versions in samples.
>>>> There are two potential problems that I am aware of:
>>>>
>>>> 1) For both Blog-Sample and AriesTrader there are hard-coded
>>>> version references in the Equinox assembly config.ini file which are
>>>> used to specify the bundle jars that are to be started for the
>>>> assembly. Naturally, the versions of the aries bundles in this file
>>>> won't be updated by the maven-release-plugin. I'm not sure of a
>>>> good solution for this beyond just manually changing the config.ini
>>>> files prior to creating a release candidate.
>>>
>>> I think we might be able to work around this by putting the
>>> config.ini files in src/main/resources/filtered-resources and
>>> defining a bunch of properties in an appropriate pom and using them
>>> for the version imports of the aries subproject dependencyManagement
>>> imports in the samples root pom. I haven't tried this yet...
>>>
>>
>> I think I can do this bit fairly soon...
>>
>> thanks
>> david jencks
>>
>>
>>>>
>>>> 2) I think there is still an unresolved issue related to
>>>> Blog-Sample and how we might be able to demonstrate a bundle upgrade
>>>> scenario. I'm not sure if this capability is included yet in
>>>> Blog-Sample - so it might still be a non-issue at the moment.
>>>> However, we had some discussion on this a week ago or so related to
>>>> how we might be able to include multiple versions of components in
>>>> the sample so that an upgrade scenario could be demonstrated. If
>>>> that is still a goal for the 0.1 release we will need to come up
>>>> with some solution.
>>>
>>> no ideas from me on this one :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Joe
>>>>
>>>>
>>>> David Jencks wrote:
>>>>> I think everything is ok.... I think (at least with dryRun=true)
>>>>> that the release plugin builds the project first as-is and checks
>>>>> that signing etc works.
>>>>> I added autoVersionSubmodules=true in the root parent pom which
>>>>> will make things work more smoothly :-)
>>>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>>>>> first, I'm happy to do this if you want.
>>>>> thanks
>>>>> david jencks
>>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>>> scratch that. I'm working thru this:
>>>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>>>> there's several steps I haven't done.
>>>>>>
>>>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>>>>> I've done most of what I think is needed for aries to be basically
>>>>>>>> releasable. There are some bits left and possibly stuff I've
>>>>>>>> missed.
>>>>>>>>
>>>>>>>> 1. legal file review. There are a bunch of NOTICE files that
>>>>>>>> claim that
>>>>>>>> work from osgi is included. Really? license and notice files
>>>>>>>> are supposed
>>>>>>>> to apply to what is actually in an artifact or checkout. Are
>>>>>>>> some of our
>>>>>>>> source files copied from an osgi source? Also all the legal
>>>>>>>> files that end
>>>>>>>> up in binary artifacts need to be checked. Also we need to run
>>>>>>>> the rat
>>>>>>>> plugin: this should be configured in the default pom. Not sure
>>>>>>>> if I will
>>>>>>>> get to this.
>>>>>>>>
>>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure
>>>>>>>> how to make
>>>>>>>> sure that an eba is working so I didn't mess with this. I think
>>>>>>>> the plugin
>>>>>>>> itself is working well enough to use though.
>>>>>>>>
>>>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>>>> convenient to
>>>>>>>> have these alphabetized so I can find what I'm looking for, but
>>>>>>>> I haven't
>>>>>>>> done this in most poms. I'm not sure why there isn't a usable
>>>>>>>> tool for
>>>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>>>
>>>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>>>> dependency:analyze and
>>>>>>>> look carefully at the results. The results from this can require
>>>>>>>> interpretation so its best if someone who is very familiar with
>>>>>>>> how the code
>>>>>>>> works does this.
>>>>>>>>
>>>>>>>> 4. before a release all snapshots need to be resolved to
>>>>>>>> released versions.
>>>>>>>> I don't know if there are any snapshots.
>>>>>>>>
>>>>>>>> To summarize what I've tried to do:
>>>>>>>>
>>>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>>>> dependencies
>>>>>>>> that all projects are pretty sure to use including the pax stuff
>>>>>>>> used mostly
>>>>>>>> for testing.
>>>>>>>>
>>>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>>>
>>>>>>>> 3. each subproject has an scm element in its pom, but no others do.
>>>>>>>>
>>>>>>>> 4. each subproject has dependency management for everything
>>>>>>>> included in it.
>>>>>>>> In addition, it has its subprojects listed in dependency
>>>>>>>> management. (this
>>>>>>>> is bent slightly for the samples). This means that
>>>>>>>> (a) modules in a subproject don't need to include versions for
>>>>>>>> use of other
>>>>>>>> modules
>>>>>>>> (b) you can get dependency management for all the modules in a
>>>>>>>> subproject
>>>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>>>> samples pom
>>>>>>>> for an example).
>>>>>>>>
>>>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>>>> dependency
>>>>>>>> elements.
>>>>>>>>
>>>>>>>> Release is going to involve...
>>>>>>>>
>>>>>>>> releasing the parent
>>>>>>>
>>>>>>> In trunk/parent I tried:
>>>>>>>
>>>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>>>
>>>>>>> Providing 0.1-incubating for the release version
>>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development
>>>>>>> version
>>>>>>>
>>>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>>>
>>>>>>> [INFO] [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>>>> [INFO] [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> [INFO] [INFO] [clean:clean]
>>>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>>>> 'false'.
>>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] Building zip:
>>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>>>
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] Preparing source:jar
>>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>>>> recursive invocation.
>>>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>>>> classpath-capable package
>>>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>>>
>>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>>>
>>>>>>> Then stops at the gpg stage. I thought it would prompt me for my key
>>>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>>>
>>>>>>>> updating the parent version wherever it is used (all subproject
>>>>>>>> parents)
>>>>>>>>
>>>>>>>> releasing the subprojects in an appropriate order and updating
>>>>>>>> their
>>>>>>>> versions wherever they are used.
>>>>>>>>
>>>>>>>> It might be worthwhile changing the pom version to
>>>>>>>> 0.1-incubating-SNAPSHOT
>>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing
>>>>>>>> this because
>>>>>>>> then the versions plugin can be used to update use of a
>>>>>>>> subproject to the
>>>>>>>> newly released version of what it uses. Going from
>>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>>>
>>>>>>>> As noted in the "root" pom, don't try to release the root pom
>>>>>>>> and don't try
>>>>>>>> release everything at once from the root pom.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> I started looking into cleaning up the build, and of course it
>>>>>>>>> is taking
>>>>>>>>> longer than I expected.
>>>>>>>>>
>>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>>>
>>>>>>>>> There are some projects in application that stop compiling if you
>>>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts
>>>>>>>>> are getting on
>>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding
>>>>>>>>> exclusions to the
>>>>>>>>> dependencies seems to fix it if you can figure out where the
>>>>>>>>> out of date
>>>>>>>>> jars are coming from.
>>>>>>>>>
>>>>>>>>> The build is already much closer to a multi-release model than
>>>>>>>>> a single
>>>>>>>>> release model.
>>>>>>>>>
>>>>>>>>> I've diffed what I have so far and attached it to ARIES-173.
>>>>>>>>> It includes
>>>>>>>>> scm info and a lot of version corrections. Due to the failing
>>>>>>>>> tests I'm not
>>>>>>>>> too comfortable committing it.
>>>>>>>>>
>>>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> It 'd be great if you are willing to fix these build issues,
>>>>>>>>>> since you
>>>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>>>
>>>>>>>>>> I know the maven release plugin isn't friendly to use some
>>>>>>>>>> cases, so
>>>>>>>>>> it is best we get these resolved to make our release process a
>>>>>>>>>> bit
>>>>>>>>>> easier.
>>>>>>>>>>
>>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time
>>>>>>>>>> with the
>>>>>>>>>> release.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Lin
>>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>>>> <da...@yahoo.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I would like to understand the problems you see better, but
>>>>>>>>>>>> I do not
>>>>>>>>>>>> have
>>>>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>>>>> explain what
>>>>>>>>>>>> the
>>>>>>>>>>>> problems are, why they are problems and the solution at some
>>>>>>>>>>>> point?
>>>>>>>>>>>
>>>>>>>>>>> The biggest immediate problem is that without correct svn
>>>>>>>>>>> info you can't
>>>>>>>>>>> do
>>>>>>>>>>> a release with the release plugin. I'm pretty sure the way
>>>>>>>>>>> its set up
>>>>>>>>>>> now,
>>>>>>>>>>> when you try, the tag will be under maven's apache pom, not
>>>>>>>>>>> aries.
>>>>>>>>>>> (you'll
>>>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>>>> definitely
>>>>>>>>>>> don't
>>>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>>>
>>>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>>>> application,
>>>>>>>>>>> and samples should always be released in synchrony. Any time
>>>>>>>>>>> two of
>>>>>>>>>>> them
>>>>>>>>>>> happen to be ready for release at the same time it will be
>>>>>>>>>>> purely
>>>>>>>>>>> accidental. Right now everyone wants to get a milestone out
>>>>>>>>>>> the door,
>>>>>>>>>>> but
>>>>>>>>>>> looking at the different projects their state of completion
>>>>>>>>>>> is pretty
>>>>>>>>>>> much
>>>>>>>>>>> wildly different. A decision to release all of them at once
>>>>>>>>>>> is not
>>>>>>>>>>> based in
>>>>>>>>>>> any way on them being equally complete. I'm suggesting that
>>>>>>>>>>> since build
>>>>>>>>>>> fixes are needed anyway, why not set up a maintainable
>>>>>>>>>>> structure that
>>>>>>>>>>> will
>>>>>>>>>>> continue to work beyond this publicity release. The benefit
>>>>>>>>>>> to users is
>>>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>>>> otherwise
>>>>>>>>>>> the
>>>>>>>>>>> entire project will never be in a releasable state at once.
>>>>>>>>>>> (I'm only
>>>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>>>
>>>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>>>> gyrations that
>>>>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>>>>> artifact) out
>>>>>>>>>>> the
>>>>>>>>>>> door. This might be ok for one release but (a) I think this
>>>>>>>>>>> can be done
>>>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>>>> eba-maven-plugin
>>>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>>>
>>>>>>>>>>> I'm willing to fix the build and probably work on an eba
>>>>>>>>>>> plugin, but
>>>>>>>>>>> want to
>>>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Alasdair
>>>>>>>>>>>>
>>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks
>>>>>>>>>>>> <da...@yahoo.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> This discussion got me worried enough to take a look at the
>>>>>>>>>>>>> aries
>>>>>>>>>>>>> build.
>>>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>>>
>>>>>>>>>>>>> While it might feel good to try to push out a release as
>>>>>>>>>>>>> fast as
>>>>>>>>>>>>> possible
>>>>>>>>>>>>> I'd prefer to see a sustainable build system in place
>>>>>>>>>>>>> first. So far
>>>>>>>>>>>>> it
>>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>>>> coupled
>>>>>>>>>>>>> subprojects. Building them all at once is not going to
>>>>>>>>>>>>> work for long.
>>>>>>>>>>>>> I
>>>>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>>>>> system now.
>>>>>>>>>>>>> To me
>>>>>>>>>>>>> this means:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>>>>>>> released
>>>>>>>>>>>>> (mostly
>>>>>>>>>>>>> svn info) (right now this is completely missing everywhere
>>>>>>>>>>>>> as far as
>>>>>>>>>>>>> I can
>>>>>>>>>>>>> see, which will result in ares getting tagged into svn as
>>>>>>>>>>>>> part of the
>>>>>>>>>>>>> apache
>>>>>>>>>>>>> pom)
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can still have a "fake" pom that builds everything, but
>>>>>>>>>>>>> it won't be
>>>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Having separately released subprojects does not prevent
>>>>>>>>>>>>> having a
>>>>>>>>>>>>> single
>>>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>>>>>>> filtered-resources to distinguish when filtering is called
>>>>>>>>>>>>> for.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In addition relevant to this particular bit of the thread,
>>>>>>>>>>>>> we need an
>>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a
>>>>>>>>>>>>> first release
>>>>>>>>>>>>> would
>>>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If there's general agreement I can spend some time playing
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> build
>>>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thoughts?
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd also like to see us release the sample applications
>>>>>>>>>>>>>>>> but I think
>>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and
>>>>>>>>>>>>>>>> AriesTrader
>>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly
>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>>> being pushed into my local repo. I've made some changes
>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create
>>>>>>>>>>>>>>> the .eba
>>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>>>>>>>>>>> the .eba for
>>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do
>>>>>>>>>>>>>> you know if
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>>> when we do
>>>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>>>> mechanism for
>>>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think the result is that the eba will not be available
>>>>>>>>>>>>>>>> in a maven
>>>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One of the differences is that AriesTrader first
>>>>>>>>>>>>>>>> generates a jar
>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba.
>>>>>>>>>>>>>>>> The jar will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that
>>>>>>>>>>>>>>>> is correct
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>>>>> approach long
>>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact
>>>>>>>>>>>>>>> from maven
>>>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work
>>>>>>>>>>>>>> out - is
>>>>>>>>>>>>>> there anything wrong with the approach I mentioned earlier
>>>>>>>>>>>>>> of just
>>>>>>>>>>>>>> using the
>>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the
>>>>>>>>>>>>>> current
>>>>>>>>>>>>>> application
>>>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>>>> The transaction component is functional and we've been
>>>>>>>>>>>>>>>>> using it
>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn
>>>>>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ...
>>>>>>>>>>>>>>>>>> and for
>>>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me get
>>>>>>>>>>>>>>>>>> a better
>>>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I was really just interested in the general objectives
>>>>>>>>>>>>>>>>>> and timing
>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in
>>>>>>>>>>>>>>>>>> Feb means
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>>>>>> little too
>>>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>>> and planning along the same lines (or understand
>>>>>>>>>>>>>>>>>> quickly if there
>>>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are
>>>>>>>>>>>>>>>>>> thinking of
>>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>>>>> getting more
>>>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in
>>>>>>>>>>>>>>>>>> or out -
>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> general it doesn't make sense to release things that
>>>>>>>>>>>>>>>>>> aren't
>>>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect
>>>>>>>>>>>>>>>>>> not all of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but
>>>>>>>>>>>>>>>>>>> am now out
>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to
>>>>>>>>>>>>>>>>>>> get what we
>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires.
>>>>>>>>>>>>>>>>>>> So 'must
>>>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each
>>>>>>>>>>>>>>>>>>> main area of
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>>>>> unknowns -
>>>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in
>>>>>>>>>>>>>>>>>>> feb. If
>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0
>>>>>>>>>>>>>>>>>>> to 0.1 and
>>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1
>>>>>>>>>>>>>>>>>>> to target a
>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn
>>>>>>>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding
>>>>>>>>>>>>>>>>>>>> the release
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep
>>>>>>>>>>>>>>>>>>>> updated as we
>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we
>>>>>>>>>>>>>>>>>>>> would like
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>>>>>>> dates for
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any
>>>>>>>>>>>>>>>>>>>>>> help.
>>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>>>>> interesting to
>>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one
>>>>>>>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release
>>>>>>>>>>>>>>>>>>>>>>>> as an
>>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache
>>>>>>>>>>>>>>>>>>>>>>>> release is an
>>>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see
>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>> --
>>>> Joe
>>>
>>
>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
David Jencks wrote:
> I changed the versions to 0.1-incubating-SNAPSHOT (except for some
> blog-sample, see below) and filtered the config.ini files.
>
> I'm still seeing some test failures in jpa-container-itests. I can't
> figure out how these work or why they do or don't fail, I'm hoping
> someone who does can figure out what's wrong.
I just checked in a change in rev. 919023 that fixes the imports and
makes the test pass. If this isn't the right fix please undo it ... but
it works for me and makes the jpa bundles usable in my equinox assembly
for AriesTrader.
Joe
>
> The blog sample had been changed to use release versions. This is not
> OK for anything that might possibly ever be released. I changed them
> back to 0.1-incubating-SNAPSHOT and the 1.1.0 to
> 0.1.0.1-incubating-SNAPSHOT. If the idea is to show how a version
> upgrade can install a new feature I'd expect the new versions to work
> and to be consistent with any likely versions used in the future. I'm
> not entirely sure what osgi version 0.1.0.1-incubating will turn into,
> hopefully something plausible and larger than 0.1-incubating.
>
> If this is not ok for the purposes of the sample and you really need
> something like 1.0.0 and 1.1.0 then we'll have to find a way so that
> this project can be built but never released. I think that it is
> possible to configure deployment to a repository under
> samples/blog-sample/target which would work for this purpose. However
> this is unusual and I hope we can avoid it.
>
> Is anyone planning to convert the eba generation to using the new plugin?
>
> thanks
> david jencks
>
> On Mar 3, 2010, at 11:00 PM, David Jencks wrote:
>
>>
>> On Mar 2, 2010, at 11:06 AM, David Jencks wrote:
>>
>>>
>>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>>>
>>>> I agree that we should make a global change to
>>>> 0.1-incubating-SNAPSHOT first. Why wouldn't we just do that now?
>>>
>>> I started doing some experiments here...
>>>
>>> running
>>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>>>
>>> in root and parent upgrades everything maven knows about just fine.
>>> However there's (1) mentioned below and also a hardcoded version in
>>> two blueprint-itests.
>>>
>>> According to
>>>
>>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>>>
>>> we should be able to replace the hardcoded versions with
>>> .versionAsInProject()
>>>
>>> if we run the maven-paxexam-plugin on the project. However I can't
>>> get it to work yet.
>>
>> I eventually figured enough about how pax-exam works to fix this. I
>> (hopefully temporarily) borrowed some test code from pax exam and
>> entered a patch at http://issues.ops4j.org/browse/PAXEXAM-171. If
>> there are no better ideas or objections I expect to commit it in a few
>> days. I'd guess at this point people might rather wait till after an
>> aries release or pax-exam release, whichever comes first, to move to
>> using the code once it gets in pax-exam?
>>
>>
>> I'm seeing a bunch of test failures later on with the changed
>> version. If I can't figure out what is causing them reasonably
>> quickly I'm going to commit the version change and suggest that
>> someone who understands how the tests work make them version-independent.
>>
>>
>>>>
>>>> Just a heads-up on some other issues related to versions in samples.
>>>> There are two potential problems that I am aware of:
>>>>
>>>> 1) For both Blog-Sample and AriesTrader there are hard-coded
>>>> version references in the Equinox assembly config.ini file which are
>>>> used to specify the bundle jars that are to be started for the
>>>> assembly. Naturally, the versions of the aries bundles in this file
>>>> won't be updated by the maven-release-plugin. I'm not sure of a
>>>> good solution for this beyond just manually changing the config.ini
>>>> files prior to creating a release candidate.
>>>
>>> I think we might be able to work around this by putting the
>>> config.ini files in src/main/resources/filtered-resources and
>>> defining a bunch of properties in an appropriate pom and using them
>>> for the version imports of the aries subproject dependencyManagement
>>> imports in the samples root pom. I haven't tried this yet...
>>>
>>
>> I think I can do this bit fairly soon...
>>
>> thanks
>> david jencks
>>
>>
>>>>
>>>> 2) I think there is still an unresolved issue related to
>>>> Blog-Sample and how we might be able to demonstrate a bundle upgrade
>>>> scenario. I'm not sure if this capability is included yet in
>>>> Blog-Sample - so it might still be a non-issue at the moment.
>>>> However, we had some discussion on this a week ago or so related to
>>>> how we might be able to include multiple versions of components in
>>>> the sample so that an upgrade scenario could be demonstrated. If
>>>> that is still a goal for the 0.1 release we will need to come up
>>>> with some solution.
>>>
>>> no ideas from me on this one :-)
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Joe
>>>>
>>>>
>>>> David Jencks wrote:
>>>>> I think everything is ok.... I think (at least with dryRun=true)
>>>>> that the release plugin builds the project first as-is and checks
>>>>> that signing etc works.
>>>>> I added autoVersionSubmodules=true in the root parent pom which
>>>>> will make things work more smoothly :-)
>>>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>>>>> first, I'm happy to do this if you want.
>>>>> thanks
>>>>> david jencks
>>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>>> scratch that. I'm working thru this:
>>>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>>>> there's several steps I haven't done.
>>>>>>
>>>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>>>>> I've done most of what I think is needed for aries to be basically
>>>>>>>> releasable. There are some bits left and possibly stuff I've
>>>>>>>> missed.
>>>>>>>>
>>>>>>>> 1. legal file review. There are a bunch of NOTICE files that
>>>>>>>> claim that
>>>>>>>> work from osgi is included. Really? license and notice files
>>>>>>>> are supposed
>>>>>>>> to apply to what is actually in an artifact or checkout. Are
>>>>>>>> some of our
>>>>>>>> source files copied from an osgi source? Also all the legal
>>>>>>>> files that end
>>>>>>>> up in binary artifacts need to be checked. Also we need to run
>>>>>>>> the rat
>>>>>>>> plugin: this should be configured in the default pom. Not sure
>>>>>>>> if I will
>>>>>>>> get to this.
>>>>>>>>
>>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure
>>>>>>>> how to make
>>>>>>>> sure that an eba is working so I didn't mess with this. I think
>>>>>>>> the plugin
>>>>>>>> itself is working well enough to use though.
>>>>>>>>
>>>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>>>> convenient to
>>>>>>>> have these alphabetized so I can find what I'm looking for, but
>>>>>>>> I haven't
>>>>>>>> done this in most poms. I'm not sure why there isn't a usable
>>>>>>>> tool for
>>>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>>>
>>>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>>>> dependency:analyze and
>>>>>>>> look carefully at the results. The results from this can require
>>>>>>>> interpretation so its best if someone who is very familiar with
>>>>>>>> how the code
>>>>>>>> works does this.
>>>>>>>>
>>>>>>>> 4. before a release all snapshots need to be resolved to
>>>>>>>> released versions.
>>>>>>>> I don't know if there are any snapshots.
>>>>>>>>
>>>>>>>> To summarize what I've tried to do:
>>>>>>>>
>>>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>>>> dependencies
>>>>>>>> that all projects are pretty sure to use including the pax stuff
>>>>>>>> used mostly
>>>>>>>> for testing.
>>>>>>>>
>>>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>>>
>>>>>>>> 3. each subproject has an scm element in its pom, but no others do.
>>>>>>>>
>>>>>>>> 4. each subproject has dependency management for everything
>>>>>>>> included in it.
>>>>>>>> In addition, it has its subprojects listed in dependency
>>>>>>>> management. (this
>>>>>>>> is bent slightly for the samples). This means that
>>>>>>>> (a) modules in a subproject don't need to include versions for
>>>>>>>> use of other
>>>>>>>> modules
>>>>>>>> (b) you can get dependency management for all the modules in a
>>>>>>>> subproject
>>>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>>>> samples pom
>>>>>>>> for an example).
>>>>>>>>
>>>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>>>> dependency
>>>>>>>> elements.
>>>>>>>>
>>>>>>>> Release is going to involve...
>>>>>>>>
>>>>>>>> releasing the parent
>>>>>>>
>>>>>>> In trunk/parent I tried:
>>>>>>>
>>>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>>>
>>>>>>> Providing 0.1-incubating for the release version
>>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development
>>>>>>> version
>>>>>>>
>>>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>>>
>>>>>>> [INFO] [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>>>> [INFO] [INFO]
>>>>>>> ------------------------------------------------------------------------
>>>>>>>
>>>>>>> [INFO] [INFO] [clean:clean]
>>>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>>>> 'false'.
>>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] Building zip:
>>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>>>
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>>> skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>>> added, skipping
>>>>>>> [INFO] [INFO] Preparing source:jar
>>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>>>> recursive invocation.
>>>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>>>> classpath-capable package
>>>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>>>
>>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>>>
>>>>>>> Then stops at the gpg stage. I thought it would prompt me for my key
>>>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>>>
>>>>>>>> updating the parent version wherever it is used (all subproject
>>>>>>>> parents)
>>>>>>>>
>>>>>>>> releasing the subprojects in an appropriate order and updating
>>>>>>>> their
>>>>>>>> versions wherever they are used.
>>>>>>>>
>>>>>>>> It might be worthwhile changing the pom version to
>>>>>>>> 0.1-incubating-SNAPSHOT
>>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing
>>>>>>>> this because
>>>>>>>> then the versions plugin can be used to update use of a
>>>>>>>> subproject to the
>>>>>>>> newly released version of what it uses. Going from
>>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>>>
>>>>>>>> As noted in the "root" pom, don't try to release the root pom
>>>>>>>> and don't try
>>>>>>>> release everything at once from the root pom.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>>>
>>>>>>>>> I started looking into cleaning up the build, and of course it
>>>>>>>>> is taking
>>>>>>>>> longer than I expected.
>>>>>>>>>
>>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>>>
>>>>>>>>> There are some projects in application that stop compiling if you
>>>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts
>>>>>>>>> are getting on
>>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding
>>>>>>>>> exclusions to the
>>>>>>>>> dependencies seems to fix it if you can figure out where the
>>>>>>>>> out of date
>>>>>>>>> jars are coming from.
>>>>>>>>>
>>>>>>>>> The build is already much closer to a multi-release model than
>>>>>>>>> a single
>>>>>>>>> release model.
>>>>>>>>>
>>>>>>>>> I've diffed what I have so far and attached it to ARIES-173.
>>>>>>>>> It includes
>>>>>>>>> scm info and a lot of version corrections. Due to the failing
>>>>>>>>> tests I'm not
>>>>>>>>> too comfortable committing it.
>>>>>>>>>
>>>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>>>
>>>>>>>>>> Hi David,
>>>>>>>>>>
>>>>>>>>>> It 'd be great if you are willing to fix these build issues,
>>>>>>>>>> since you
>>>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>>>
>>>>>>>>>> I know the maven release plugin isn't friendly to use some
>>>>>>>>>> cases, so
>>>>>>>>>> it is best we get these resolved to make our release process a
>>>>>>>>>> bit
>>>>>>>>>> easier.
>>>>>>>>>>
>>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time
>>>>>>>>>> with the
>>>>>>>>>> release.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> Lin
>>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>>>>>> <da...@yahoo.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I would like to understand the problems you see better, but
>>>>>>>>>>>> I do not
>>>>>>>>>>>> have
>>>>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>>>>> explain what
>>>>>>>>>>>> the
>>>>>>>>>>>> problems are, why they are problems and the solution at some
>>>>>>>>>>>> point?
>>>>>>>>>>>
>>>>>>>>>>> The biggest immediate problem is that without correct svn
>>>>>>>>>>> info you can't
>>>>>>>>>>> do
>>>>>>>>>>> a release with the release plugin. I'm pretty sure the way
>>>>>>>>>>> its set up
>>>>>>>>>>> now,
>>>>>>>>>>> when you try, the tag will be under maven's apache pom, not
>>>>>>>>>>> aries.
>>>>>>>>>>> (you'll
>>>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>>>> definitely
>>>>>>>>>>> don't
>>>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>>>
>>>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>>>> application,
>>>>>>>>>>> and samples should always be released in synchrony. Any time
>>>>>>>>>>> two of
>>>>>>>>>>> them
>>>>>>>>>>> happen to be ready for release at the same time it will be
>>>>>>>>>>> purely
>>>>>>>>>>> accidental. Right now everyone wants to get a milestone out
>>>>>>>>>>> the door,
>>>>>>>>>>> but
>>>>>>>>>>> looking at the different projects their state of completion
>>>>>>>>>>> is pretty
>>>>>>>>>>> much
>>>>>>>>>>> wildly different. A decision to release all of them at once
>>>>>>>>>>> is not
>>>>>>>>>>> based in
>>>>>>>>>>> any way on them being equally complete. I'm suggesting that
>>>>>>>>>>> since build
>>>>>>>>>>> fixes are needed anyway, why not set up a maintainable
>>>>>>>>>>> structure that
>>>>>>>>>>> will
>>>>>>>>>>> continue to work beyond this publicity release. The benefit
>>>>>>>>>>> to users is
>>>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>>>> otherwise
>>>>>>>>>>> the
>>>>>>>>>>> entire project will never be in a releasable state at once.
>>>>>>>>>>> (I'm only
>>>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>>>
>>>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>>>> gyrations that
>>>>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>>>>> artifact) out
>>>>>>>>>>> the
>>>>>>>>>>> door. This might be ok for one release but (a) I think this
>>>>>>>>>>> can be done
>>>>>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>>>>>> eba-maven-plugin
>>>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>>>
>>>>>>>>>>> I'm willing to fix the build and probably work on an eba
>>>>>>>>>>> plugin, but
>>>>>>>>>>> want to
>>>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks
>>>>>>>>>>>> Alasdair
>>>>>>>>>>>>
>>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks
>>>>>>>>>>>> <da...@yahoo.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> This discussion got me worried enough to take a look at the
>>>>>>>>>>>>> aries
>>>>>>>>>>>>> build.
>>>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>>>
>>>>>>>>>>>>> While it might feel good to try to push out a release as
>>>>>>>>>>>>> fast as
>>>>>>>>>>>>> possible
>>>>>>>>>>>>> I'd prefer to see a sustainable build system in place
>>>>>>>>>>>>> first. So far
>>>>>>>>>>>>> it
>>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>>>> coupled
>>>>>>>>>>>>> subprojects. Building them all at once is not going to
>>>>>>>>>>>>> work for long.
>>>>>>>>>>>>> I
>>>>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>>>>> system now.
>>>>>>>>>>>>> To me
>>>>>>>>>>>>> this means:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>>>>>>> released
>>>>>>>>>>>>> (mostly
>>>>>>>>>>>>> svn info) (right now this is completely missing everywhere
>>>>>>>>>>>>> as far as
>>>>>>>>>>>>> I can
>>>>>>>>>>>>> see, which will result in ares getting tagged into svn as
>>>>>>>>>>>>> part of the
>>>>>>>>>>>>> apache
>>>>>>>>>>>>> pom)
>>>>>>>>>>>>>
>>>>>>>>>>>>> We can still have a "fake" pom that builds everything, but
>>>>>>>>>>>>> it won't be
>>>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Having separately released subprojects does not prevent
>>>>>>>>>>>>> having a
>>>>>>>>>>>>> single
>>>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>>>>>>> filtered-resources to distinguish when filtering is called
>>>>>>>>>>>>> for.
>>>>>>>>>>>>>
>>>>>>>>>>>>> In addition relevant to this particular bit of the thread,
>>>>>>>>>>>>> we need an
>>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a
>>>>>>>>>>>>> first release
>>>>>>>>>>>>> would
>>>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>>>
>>>>>>>>>>>>> If there's general agreement I can spend some time playing
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> build
>>>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>>>
>>>>>>>>>>>>> thoughts?
>>>>>>>>>>>>>
>>>>>>>>>>>>> thanks
>>>>>>>>>>>>> david jencks
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd also like to see us release the sample applications
>>>>>>>>>>>>>>>> but I think
>>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and
>>>>>>>>>>>>>>>> AriesTrader
>>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly
>>>>>>>>>>>>>>> module
>>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>>> being pushed into my local repo. I've made some changes
>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create
>>>>>>>>>>>>>>> the .eba
>>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>>>>>>>>>>> the .eba for
>>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do
>>>>>>>>>>>>>> you know if
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>>> when we do
>>>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>>>> mechanism for
>>>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think the result is that the eba will not be available
>>>>>>>>>>>>>>>> in a maven
>>>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> One of the differences is that AriesTrader first
>>>>>>>>>>>>>>>> generates a jar
>>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba.
>>>>>>>>>>>>>>>> The jar will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that
>>>>>>>>>>>>>>>> is correct
>>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>>>>> approach long
>>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact
>>>>>>>>>>>>>>> from maven
>>>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work
>>>>>>>>>>>>>> out - is
>>>>>>>>>>>>>> there anything wrong with the approach I mentioned earlier
>>>>>>>>>>>>>> of just
>>>>>>>>>>>>>> using the
>>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the
>>>>>>>>>>>>>> current
>>>>>>>>>>>>>> application
>>>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>>>> The transaction component is functional and we've been
>>>>>>>>>>>>>>>>> using it
>>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn
>>>>>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ...
>>>>>>>>>>>>>>>>>> and for
>>>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me get
>>>>>>>>>>>>>>>>>> a better
>>>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I was really just interested in the general objectives
>>>>>>>>>>>>>>>>>> and timing
>>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in
>>>>>>>>>>>>>>>>>> Feb means
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>>>>>> little too
>>>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>>> and planning along the same lines (or understand
>>>>>>>>>>>>>>>>>> quickly if there
>>>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are
>>>>>>>>>>>>>>>>>> thinking of
>>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>>>>> getting more
>>>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in
>>>>>>>>>>>>>>>>>> or out -
>>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> general it doesn't make sense to release things that
>>>>>>>>>>>>>>>>>> aren't
>>>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect
>>>>>>>>>>>>>>>>>> not all of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but
>>>>>>>>>>>>>>>>>>> am now out
>>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to
>>>>>>>>>>>>>>>>>>> get what we
>>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires.
>>>>>>>>>>>>>>>>>>> So 'must
>>>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each
>>>>>>>>>>>>>>>>>>> main area of
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>>>>> unknowns -
>>>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in
>>>>>>>>>>>>>>>>>>> feb. If
>>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0
>>>>>>>>>>>>>>>>>>> to 0.1 and
>>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1
>>>>>>>>>>>>>>>>>>> to target a
>>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn
>>>>>>>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding
>>>>>>>>>>>>>>>>>>>> the release
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep
>>>>>>>>>>>>>>>>>>>> updated as we
>>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we
>>>>>>>>>>>>>>>>>>>> would like
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>>>>>>> dates for
>>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any
>>>>>>>>>>>>>>>>>>>>>> help.
>>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>>>>> interesting to
>>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one
>>>>>>>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release
>>>>>>>>>>>>>>>>>>>>>>>> as an
>>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache
>>>>>>>>>>>>>>>>>>>>>>>> release is an
>>>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see
>>>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>>>
>>>> --
>>>> Joe
>>>
>>
>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
I changed the versions to 0.1-incubating-SNAPSHOT (except for some
blog-sample, see below) and filtered the config.ini files.
I'm still seeing some test failures in jpa-container-itests. I can't
figure out how these work or why they do or don't fail, I'm hoping
someone who does can figure out what's wrong.
The blog sample had been changed to use release versions. This is not
OK for anything that might possibly ever be released. I changed them
back to 0.1-incubating-SNAPSHOT and the 1.1.0 to 0.1.0.1-incubating-
SNAPSHOT. If the idea is to show how a version upgrade can install a
new feature I'd expect the new versions to work and to be consistent
with any likely versions used in the future. I'm not entirely sure
what osgi version 0.1.0.1-incubating will turn into, hopefully
something plausible and larger than 0.1-incubating.
If this is not ok for the purposes of the sample and you really need
something like 1.0.0 and 1.1.0 then we'll have to find a way so that
this project can be built but never released. I think that it is
possible to configure deployment to a repository under samples/blog-
sample/target which would work for this purpose. However this is
unusual and I hope we can avoid it.
Is anyone planning to convert the eba generation to using the new
plugin?
thanks
david jencks
On Mar 3, 2010, at 11:00 PM, David Jencks wrote:
>
> On Mar 2, 2010, at 11:06 AM, David Jencks wrote:
>
>>
>> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>>
>>> I agree that we should make a global change to 0.1-incubating-
>>> SNAPSHOT first. Why wouldn't we just do that now?
>>
>> I started doing some experiments here...
>>
>> running
>> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>>
>> in root and parent upgrades everything maven knows about just fine.
>> However there's (1) mentioned below and also a hardcoded version in
>> two blueprint-itests.
>>
>> According to
>>
>> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven
>> +Plugin
>>
>> we should be able to replace the hardcoded versions
>> with .versionAsInProject()
>>
>> if we run the maven-paxexam-plugin on the project. However I can't
>> get it to work yet.
>
> I eventually figured enough about how pax-exam works to fix this. I
> (hopefully temporarily) borrowed some test code from pax exam and
> entered a patch at http://issues.ops4j.org/browse/PAXEXAM-171. If
> there are no better ideas or objections I expect to commit it in a
> few days. I'd guess at this point people might rather wait till
> after an aries release or pax-exam release, whichever comes first,
> to move to using the code once it gets in pax-exam?
>
>
> I'm seeing a bunch of test failures later on with the changed
> version. If I can't figure out what is causing them reasonably
> quickly I'm going to commit the version change and suggest that
> someone who understands how the tests work make them version-
> independent.
>
>
>>>
>>> Just a heads-up on some other issues related to versions in
>>> samples. There are two potential problems that I am aware of:
>>>
>>> 1) For both Blog-Sample and AriesTrader there are hard-coded
>>> version references in the Equinox assembly config.ini file which
>>> are used to specify the bundle jars that are to be started for the
>>> assembly. Naturally, the versions of the aries bundles in this
>>> file won't be updated by the maven-release-plugin. I'm not sure
>>> of a good solution for this beyond just manually changing the
>>> config.ini files prior to creating a release candidate.
>>
>> I think we might be able to work around this by putting the
>> config.ini files in src/main/resources/filtered-resources and
>> defining a bunch of properties in an appropriate pom and using them
>> for the version imports of the aries subproject
>> dependencyManagement imports in the samples root pom. I haven't
>> tried this yet...
>>
>
> I think I can do this bit fairly soon...
>
> thanks
> david jencks
>
>
>>>
>>> 2) I think there is still an unresolved issue related to Blog-
>>> Sample and how we might be able to demonstrate a bundle upgrade
>>> scenario. I'm not sure if this capability is included yet in
>>> Blog-Sample - so it might still be a non-issue at the moment.
>>> However, we had some discussion on this a week ago or so related
>>> to how we might be able to include multiple versions of components
>>> in the sample so that an upgrade scenario could be demonstrated.
>>> If that is still a goal for the 0.1 release we will need to come
>>> up with some solution.
>>
>> no ideas from me on this one :-)
>>
>> thanks
>> david jencks
>>
>>>
>>> Joe
>>>
>>>
>>> David Jencks wrote:
>>>> I think everything is ok.... I think (at least with dryRun=true)
>>>> that the release plugin builds the project first as-is and checks
>>>> that signing etc works.
>>>> I added autoVersionSubmodules=true in the root parent pom which
>>>> will make things work more smoothly :-)
>>>> I really recommend changing the version to 0.1-incubating-
>>>> SNAPSHOT first, I'm happy to do this if you want.
>>>> thanks
>>>> david jencks
>>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>>> scratch that. I'm working thru this:
>>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>>> there's several steps I haven't done.
>>>>>
>>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com>
>>>>>> wrote:
>>>>>>> I've done most of what I think is needed for aries to be
>>>>>>> basically
>>>>>>> releasable. There are some bits left and possibly stuff I've
>>>>>>> missed.
>>>>>>>
>>>>>>> 1. legal file review. There are a bunch of NOTICE files that
>>>>>>> claim that
>>>>>>> work from osgi is included. Really? license and notice files
>>>>>>> are supposed
>>>>>>> to apply to what is actually in an artifact or checkout. Are
>>>>>>> some of our
>>>>>>> source files copied from an osgi source? Also all the legal
>>>>>>> files that end
>>>>>>> up in binary artifacts need to be checked. Also we need to
>>>>>>> run the rat
>>>>>>> plugin: this should be configured in the default pom. Not
>>>>>>> sure if I will
>>>>>>> get to this.
>>>>>>>
>>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure
>>>>>>> how to make
>>>>>>> sure that an eba is working so I didn't mess with this. I
>>>>>>> think the plugin
>>>>>>> itself is working well enough to use though.
>>>>>>>
>>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>>> convenient to
>>>>>>> have these alphabetized so I can find what I'm looking for,
>>>>>>> but I haven't
>>>>>>> done this in most poms. I'm not sure why there isn't a usable
>>>>>>> tool for
>>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>>
>>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>>> dependency:analyze and
>>>>>>> look carefully at the results. The results from this can
>>>>>>> require
>>>>>>> interpretation so its best if someone who is very familiar
>>>>>>> with how the code
>>>>>>> works does this.
>>>>>>>
>>>>>>> 4. before a release all snapshots need to be resolved to
>>>>>>> released versions.
>>>>>>> I don't know if there are any snapshots.
>>>>>>>
>>>>>>> To summarize what I've tried to do:
>>>>>>>
>>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>>> dependencies
>>>>>>> that all projects are pretty sure to use including the pax
>>>>>>> stuff used mostly
>>>>>>> for testing.
>>>>>>>
>>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>>
>>>>>>> 3. each subproject has an scm element in its pom, but no
>>>>>>> others do.
>>>>>>>
>>>>>>> 4. each subproject has dependency management for everything
>>>>>>> included in it.
>>>>>>> In addition, it has its subprojects listed in dependency
>>>>>>> management. (this
>>>>>>> is bent slightly for the samples). This means that
>>>>>>> (a) modules in a subproject don't need to include versions for
>>>>>>> use of other
>>>>>>> modules
>>>>>>> (b) you can get dependency management for all the modules in a
>>>>>>> subproject
>>>>>>> by depending on the subproject pom with scope import. (see
>>>>>>> the samples pom
>>>>>>> for an example).
>>>>>>>
>>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>>> dependency
>>>>>>> elements.
>>>>>>>
>>>>>>> Release is going to involve...
>>>>>>>
>>>>>>> releasing the parent
>>>>>>
>>>>>> In trunk/parent I tried:
>>>>>>
>>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>>
>>>>>> Providing 0.1-incubating for the release version
>>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development
>>>>>> version
>>>>>>
>>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>>
>>>>>> [INFO] [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>>> [INFO] [INFO]
>>>>>> ------------------------------------------------------------------------
>>>>>> [INFO] [INFO] [clean:clean]
>>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class
>>>>>> =>
>>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on =>
>>>>>> 'false'.
>>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound
>>>>>> => 'false'.
>>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>>> [INFO] [INFO] [assembly:single {execution: source-release-
>>>>>> assembly}]
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>> skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>> added, skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>> added, skipping
>>>>>> [INFO] [INFO] Building zip:
>>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target
>>>>>> \parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>>> skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>>> added, skipping
>>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>>> added, skipping
>>>>>> [INFO] [INFO] Preparing source:jar
>>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>>> recursive invocation.
>>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>>> classpath-capable package
>>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>>
>>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>>
>>>>>> Then stops at the gpg stage. I thought it would prompt me for
>>>>>> my key
>>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>>
>>>>>>> updating the parent version wherever it is used (all
>>>>>>> subproject parents)
>>>>>>>
>>>>>>> releasing the subprojects in an appropriate order and updating
>>>>>>> their
>>>>>>> versions wherever they are used.
>>>>>>>
>>>>>>> It might be worthwhile changing the pom version to 0.1-
>>>>>>> incubating-SNAPSHOT
>>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing
>>>>>>> this because
>>>>>>> then the versions plugin can be used to update use of a
>>>>>>> subproject to the
>>>>>>> newly released version of what it uses. Going from
>>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>>
>>>>>>> As noted in the "root" pom, don't try to release the root pom
>>>>>>> and don't try
>>>>>>> release everything at once from the root pom.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>>
>>>>>>>> I started looking into cleaning up the build, and of course
>>>>>>>> it is taking
>>>>>>>> longer than I expected.
>>>>>>>>
>>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>>
>>>>>>>> There are some projects in application that stop compiling if
>>>>>>>> you
>>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts
>>>>>>>> are getting on
>>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding
>>>>>>>> exclusions to the
>>>>>>>> dependencies seems to fix it if you can figure out where the
>>>>>>>> out of date
>>>>>>>> jars are coming from.
>>>>>>>>
>>>>>>>> The build is already much closer to a multi-release model
>>>>>>>> than a single
>>>>>>>> release model.
>>>>>>>>
>>>>>>>> I've diffed what I have so far and attached it to ARIES-173.
>>>>>>>> It includes
>>>>>>>> scm info and a lot of version corrections. Due to the
>>>>>>>> failing tests I'm not
>>>>>>>> too comfortable committing it.
>>>>>>>>
>>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>>
>>>>>>>>> Hi David,
>>>>>>>>>
>>>>>>>>> It 'd be great if you are willing to fix these build issues,
>>>>>>>>> since you
>>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>>
>>>>>>>>> I know the maven release plugin isn't friendly to use some
>>>>>>>>> cases, so
>>>>>>>>> it is best we get these resolved to make our release process
>>>>>>>>> a bit
>>>>>>>>> easier.
>>>>>>>>>
>>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time
>>>>>>>>> with the
>>>>>>>>> release.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> Lin
>>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <david_jencks@yahoo.com
>>>>>>>>> >
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> I would like to understand the problems you see better,
>>>>>>>>>>> but I do not
>>>>>>>>>>> have
>>>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>>>> explain what
>>>>>>>>>>> the
>>>>>>>>>>> problems are, why they are problems and the solution at
>>>>>>>>>>> some point?
>>>>>>>>>>
>>>>>>>>>> The biggest immediate problem is that without correct svn
>>>>>>>>>> info you can't
>>>>>>>>>> do
>>>>>>>>>> a release with the release plugin. I'm pretty sure the way
>>>>>>>>>> its set up
>>>>>>>>>> now,
>>>>>>>>>> when you try, the tag will be under maven's apache pom, not
>>>>>>>>>> aries.
>>>>>>>>>> (you'll
>>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>>> definitely
>>>>>>>>>> don't
>>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>>
>>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>>> application,
>>>>>>>>>> and samples should always be released in synchrony. Any
>>>>>>>>>> time two of
>>>>>>>>>> them
>>>>>>>>>> happen to be ready for release at the same time it will be
>>>>>>>>>> purely
>>>>>>>>>> accidental. Right now everyone wants to get a milestone
>>>>>>>>>> out the door,
>>>>>>>>>> but
>>>>>>>>>> looking at the different projects their state of completion
>>>>>>>>>> is pretty
>>>>>>>>>> much
>>>>>>>>>> wildly different. A decision to release all of them at
>>>>>>>>>> once is not
>>>>>>>>>> based in
>>>>>>>>>> any way on them being equally complete. I'm suggesting
>>>>>>>>>> that since build
>>>>>>>>>> fixes are needed anyway, why not set up a maintainable
>>>>>>>>>> structure that
>>>>>>>>>> will
>>>>>>>>>> continue to work beyond this publicity release. The
>>>>>>>>>> benefit to users is
>>>>>>>>>> that aries will be able to release bits in a timely
>>>>>>>>>> fashion; otherwise
>>>>>>>>>> the
>>>>>>>>>> entire project will never be in a releasable state at once.
>>>>>>>>>> (I'm only
>>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>>
>>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>>> gyrations that
>>>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>>>> artifact) out
>>>>>>>>>> the
>>>>>>>>>> door. This might be ok for one release but (a) I think
>>>>>>>>>> this can be done
>>>>>>>>>> directly with the assembly plugin short term and (b) an eba-
>>>>>>>>>> maven-plugin
>>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>>
>>>>>>>>>> I'm willing to fix the build and probably work on an eba
>>>>>>>>>> plugin, but
>>>>>>>>>> want to
>>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>> Alasdair
>>>>>>>>>>>
>>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <david_jencks@yahoo.com
>>>>>>>>>>> > wrote:
>>>>>>>>>>>
>>>>>>>>>>>> This discussion got me worried enough to take a look at
>>>>>>>>>>>> the aries
>>>>>>>>>>>> build.
>>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>>
>>>>>>>>>>>> While it might feel good to try to push out a release as
>>>>>>>>>>>> fast as
>>>>>>>>>>>> possible
>>>>>>>>>>>> I'd prefer to see a sustainable build system in place
>>>>>>>>>>>> first. So far
>>>>>>>>>>>> it
>>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>>> coupled
>>>>>>>>>>>> subprojects. Building them all at once is not going to
>>>>>>>>>>>> work for long.
>>>>>>>>>>>> I
>>>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>>>> system now.
>>>>>>>>>>>> To me
>>>>>>>>>>>> this means:
>>>>>>>>>>>>
>>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>>>>>> released
>>>>>>>>>>>> (mostly
>>>>>>>>>>>> svn info) (right now this is completely missing
>>>>>>>>>>>> everywhere as far as
>>>>>>>>>>>> I can
>>>>>>>>>>>> see, which will result in ares getting tagged into svn as
>>>>>>>>>>>> part of the
>>>>>>>>>>>> apache
>>>>>>>>>>>> pom)
>>>>>>>>>>>>
>>>>>>>>>>>> We can still have a "fake" pom that builds everything,
>>>>>>>>>>>> but it won't be
>>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>>
>>>>>>>>>>>> Having separately released subprojects does not prevent
>>>>>>>>>>>> having a
>>>>>>>>>>>> single
>>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>>
>>>>>>>>>>>> I'd suggest a few other pom tweaks such as using
>>>>>>>>>>>> resources and
>>>>>>>>>>>> filtered-resources to distinguish when filtering is
>>>>>>>>>>>> called for.
>>>>>>>>>>>>
>>>>>>>>>>>> In addition relevant to this particular bit of the
>>>>>>>>>>>> thread, we need an
>>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a
>>>>>>>>>>>> first release
>>>>>>>>>>>> would
>>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>>
>>>>>>>>>>>> If there's general agreement I can spend some time
>>>>>>>>>>>> playing with the
>>>>>>>>>>>> build
>>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>>
>>>>>>>>>>>> thoughts?
>>>>>>>>>>>>
>>>>>>>>>>>> thanks
>>>>>>>>>>>> david jencks
>>>>>>>>>>>>
>>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd also like to see us release the sample
>>>>>>>>>>>>>>> applications but I think
>>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>>> at least one complication. Both Blog Sample and
>>>>>>>>>>>>>>> AriesTrader
>>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly
>>>>>>>>>>>>>> module
>>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>>> being pushed into my local repo. I've made some changes
>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to
>>>>>>>>>>>>>> create the .eba
>>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>>>>>>>>>> the .eba for
>>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do
>>>>>>>>>>>>> you know if
>>>>>>>>>>>>> it
>>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>>> artifacts
>>>>>>>>>>>>> when we do
>>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>>> mechanism for
>>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think the result is that the eba will not be
>>>>>>>>>>>>>>> available in a maven
>>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> One of the differences is that AriesTrader first
>>>>>>>>>>>>>>> generates a jar
>>>>>>>>>>>>>>> using
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba.
>>>>>>>>>>>>>>> The jar will
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>>> even
>>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that
>>>>>>>>>>>>>>> is correct
>>>>>>>>>>>>>>> then
>>>>>>>>>>>>>>> perhaps delivery of an application jar is an
>>>>>>>>>>>>>>> acceptable approach
>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my
>>>>>>>>>>>>>>> equinox
>>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the
>>>>>>>>>>>>>>> individual
>>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>>>> approach long
>>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and
>>>>>>>>>>>>>> use the
>>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact
>>>>>>>>>>>>>> from maven
>>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't
>>>>>>>>>>>>> work out - is
>>>>>>>>>>>>> there anything wrong with the approach I mentioned
>>>>>>>>>>>>> earlier of just
>>>>>>>>>>>>> using the
>>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the
>>>>>>>>>>>>> current
>>>>>>>>>>>>> application
>>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't think applications are really usable yet and
>>>>>>>>>>>>>>>> I haven't
>>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>>> The transaction component is functional and we've
>>>>>>>>>>>>>>>> been using it
>>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm
>>>>>>>>>>>>>>>> not talking
>>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <joebohn@gmail.com
>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks for the response (even while on
>>>>>>>>>>>>>>>>> vacation!) ... and for
>>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>>> to be the release manager. Your response helps me
>>>>>>>>>>>>>>>>> get a better
>>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I was really just interested in the general
>>>>>>>>>>>>>>>>> objectives and timing
>>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out
>>>>>>>>>>>>>>>>> in Feb means
>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>>>>> little too
>>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The more communication the better. It's important
>>>>>>>>>>>>>>>>> to get
>>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>>> and planning along the same lines (or understand
>>>>>>>>>>>>>>>>> quickly if there
>>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are
>>>>>>>>>>>>>>>>> thinking of
>>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>>>> getting more
>>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be
>>>>>>>>>>>>>>>>> in or out -
>>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> general it doesn't make sense to release things that
>>>>>>>>>>>>>>>>> aren't
>>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I
>>>>>>>>>>>>>>>>> suspect not all of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday
>>>>>>>>>>>>>>>>>> but am now out
>>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to
>>>>>>>>>>>>>>>>>> get what we
>>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires.
>>>>>>>>>>>>>>>>>> So 'must
>>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each
>>>>>>>>>>>>>>>>>> main area of
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>>>> unknowns -
>>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in
>>>>>>>>>>>>>>>>>> feb. If
>>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version
>>>>>>>>>>>>>>>>>> 1.0 to 0.1 and
>>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1
>>>>>>>>>>>>>>>>>> to target a
>>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <joebohn@gmail.com
>>>>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding
>>>>>>>>>>>>>>>>>>> the release
>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize
>>>>>>>>>>>>>>>>>>> your thoughts
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep
>>>>>>>>>>>>>>>>>>> updated as we
>>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>>> Of particular interest would be the content that
>>>>>>>>>>>>>>>>>>> we would like
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider
>>>>>>>>>>>>>>>>>>> "must have" from
>>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>>>>>> dates for
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate
>>>>>>>>>>>>>>>>>>> the release.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gnodet@gmail.com
>>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need
>>>>>>>>>>>>>>>>>>>>> any help.
>>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>>>> interesting to
>>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one
>>>>>>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release
>>>>>>>>>>>>>>>>>>>>>> manager.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release
>>>>>>>>>>>>>>>>>>>>>>> with all
>>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint
>>>>>>>>>>>>>>>>>>>>>>> release as an
>>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache
>>>>>>>>>>>>>>>>>>>>>>> release is an
>>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to
>>>>>>>>>>>>>>>>>>>>>>> see this
>>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>
>>>
>>> --
>>> Joe
>>
>
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
On Mar 2, 2010, at 11:06 AM, David Jencks wrote:
>
> On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
>
>> I agree that we should make a global change to 0.1-incubating-
>> SNAPSHOT first. Why wouldn't we just do that now?
>
> I started doing some experiments here...
>
> running
> mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
>
> in root and parent upgrades everything maven knows about just fine.
> However there's (1) mentioned below and also a hardcoded version in
> two blueprint-itests.
>
> According to
>
> http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
>
> we should be able to replace the hardcoded versions
> with .versionAsInProject()
>
> if we run the maven-paxexam-plugin on the project. However I can't
> get it to work yet.
I eventually figured enough about how pax-exam works to fix this. I
(hopefully temporarily) borrowed some test code from pax exam and
entered a patch at http://issues.ops4j.org/browse/PAXEXAM-171. If
there are no better ideas or objections I expect to commit it in a few
days. I'd guess at this point people might rather wait till after an
aries release or pax-exam release, whichever comes first, to move to
using the code once it gets in pax-exam?
I'm seeing a bunch of test failures later on with the changed
version. If I can't figure out what is causing them reasonably
quickly I'm going to commit the version change and suggest that
someone who understands how the tests work make them version-
independent.
>>
>> Just a heads-up on some other issues related to versions in
>> samples. There are two potential problems that I am aware of:
>>
>> 1) For both Blog-Sample and AriesTrader there are hard-coded
>> version references in the Equinox assembly config.ini file which
>> are used to specify the bundle jars that are to be started for the
>> assembly. Naturally, the versions of the aries bundles in this file
>> won't be updated by the maven-release-plugin. I'm not sure of a
>> good solution for this beyond just manually changing the config.ini
>> files prior to creating a release candidate.
>
> I think we might be able to work around this by putting the
> config.ini files in src/main/resources/filtered-resources and
> defining a bunch of properties in an appropriate pom and using them
> for the version imports of the aries subproject dependencyManagement
> imports in the samples root pom. I haven't tried this yet...
>
I think I can do this bit fairly soon...
thanks
david jencks
>>
>> 2) I think there is still an unresolved issue related to Blog-
>> Sample and how we might be able to demonstrate a bundle upgrade
>> scenario. I'm not sure if this capability is included yet in Blog-
>> Sample - so it might still be a non-issue at the moment. However,
>> we had some discussion on this a week ago or so related to how we
>> might be able to include multiple versions of components in the
>> sample so that an upgrade scenario could be demonstrated. If that
>> is still a goal for the 0.1 release we will need to come up with
>> some solution.
>
> no ideas from me on this one :-)
>
> thanks
> david jencks
>
>>
>> Joe
>>
>>
>> David Jencks wrote:
>>> I think everything is ok.... I think (at least with dryRun=true)
>>> that the release plugin builds the project first as-is and checks
>>> that signing etc works.
>>> I added autoVersionSubmodules=true in the root parent pom which
>>> will make things work more smoothly :-)
>>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>>> first, I'm happy to do this if you want.
>>> thanks
>>> david jencks
>>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>>> scratch that. I'm working thru this:
>>>> http://maven.apache.org/developers/release/apache-release.html as
>>>> there's several steps I haven't done.
>>>>
>>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com>
>>>>> wrote:
>>>>>> I've done most of what I think is needed for aries to be
>>>>>> basically
>>>>>> releasable. There are some bits left and possibly stuff I've
>>>>>> missed.
>>>>>>
>>>>>> 1. legal file review. There are a bunch of NOTICE files that
>>>>>> claim that
>>>>>> work from osgi is included. Really? license and notice files
>>>>>> are supposed
>>>>>> to apply to what is actually in an artifact or checkout. Are
>>>>>> some of our
>>>>>> source files copied from an osgi source? Also all the legal
>>>>>> files that end
>>>>>> up in binary artifacts need to be checked. Also we need to run
>>>>>> the rat
>>>>>> plugin: this should be configured in the default pom. Not sure
>>>>>> if I will
>>>>>> get to this.
>>>>>>
>>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure
>>>>>> how to make
>>>>>> sure that an eba is working so I didn't mess with this. I
>>>>>> think the plugin
>>>>>> itself is working well enough to use though.
>>>>>>
>>>>>> 2. ordering dependencies and dependency management. I find it
>>>>>> convenient to
>>>>>> have these alphabetized so I can find what I'm looking for, but
>>>>>> I haven't
>>>>>> done this in most poms. I'm not sure why there isn't a usable
>>>>>> tool for
>>>>>> doing this but I haven't found one. Dull but useful...
>>>>>>
>>>>>> 3. It would probably be a really good idea to run mvn
>>>>>> dependency:analyze and
>>>>>> look carefully at the results. The results from this can require
>>>>>> interpretation so its best if someone who is very familiar with
>>>>>> how the code
>>>>>> works does this.
>>>>>>
>>>>>> 4. before a release all snapshots need to be resolved to
>>>>>> released versions.
>>>>>> I don't know if there are any snapshots.
>>>>>>
>>>>>> To summarize what I've tried to do:
>>>>>>
>>>>>> 1. default-parent has dependency management for the basic osgi
>>>>>> dependencies
>>>>>> that all projects are pretty sure to use including the pax
>>>>>> stuff used mostly
>>>>>> for testing.
>>>>>>
>>>>>> 2. each subproject has legal files in its checkout root
>>>>>>
>>>>>> 3. each subproject has an scm element in its pom, but no others
>>>>>> do.
>>>>>>
>>>>>> 4. each subproject has dependency management for everything
>>>>>> included in it.
>>>>>> In addition, it has its subprojects listed in dependency
>>>>>> management. (this
>>>>>> is bent slightly for the samples). This means that
>>>>>> (a) modules in a subproject don't need to include versions for
>>>>>> use of other
>>>>>> modules
>>>>>> (b) you can get dependency management for all the modules in a
>>>>>> subproject
>>>>>> by depending on the subproject pom with scope import. (see the
>>>>>> samples pom
>>>>>> for an example).
>>>>>>
>>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>>> dependency
>>>>>> elements.
>>>>>>
>>>>>> Release is going to involve...
>>>>>>
>>>>>> releasing the parent
>>>>>
>>>>> In trunk/parent I tried:
>>>>>
>>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>>
>>>>> Providing 0.1-incubating for the release version
>>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development
>>>>> version
>>>>>
>>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>>
>>>>> [INFO] [INFO]
>>>>> ------------------------------------------------------------------------
>>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>>> [INFO] [INFO]
>>>>> ------------------------------------------------------------------------
>>>>> [INFO] [INFO] [clean:clean]
>>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>>> [INFO] [INFO] Setting property: velocimacro.messages.on =>
>>>>> 'false'.
>>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>>> 'false'.
>>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>>> [INFO] [INFO] [site:attach-descriptor]
>>>>> [INFO] [INFO] [assembly:single {execution: source-release-
>>>>> assembly}]
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>> skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>> added, skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>> added, skipping
>>>>> [INFO] [INFO] Building zip:
>>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target
>>>>> \parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>>> skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>>> added, skipping
>>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>>> added, skipping
>>>>> [INFO] [INFO] Preparing source:jar
>>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>>> recursive invocation.
>>>>> [INFO] [INFO] No goals needed for project - skipping
>>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>>> classpath-capable package
>>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>>
>>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>>
>>>>> Then stops at the gpg stage. I thought it would prompt me for my
>>>>> key
>>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>>
>>>>>> updating the parent version wherever it is used (all subproject
>>>>>> parents)
>>>>>>
>>>>>> releasing the subprojects in an appropriate order and updating
>>>>>> their
>>>>>> versions wherever they are used.
>>>>>>
>>>>>> It might be worthwhile changing the pom version to 0.1-
>>>>>> incubating-SNAPSHOT
>>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing
>>>>>> this because
>>>>>> then the versions plugin can be used to update use of a
>>>>>> subproject to the
>>>>>> newly released version of what it uses. Going from
>>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>>
>>>>>> As noted in the "root" pom, don't try to release the root pom
>>>>>> and don't try
>>>>>> release everything at once from the root pom.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>>
>>>>>>> I started looking into cleaning up the build, and of course it
>>>>>>> is taking
>>>>>>> longer than I expected.
>>>>>>>
>>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>>
>>>>>>> There are some projects in application that stop compiling if
>>>>>>> you
>>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts
>>>>>>> are getting on
>>>>>>> the maven classpath before osgi 4.2 artifacts. Adding
>>>>>>> exclusions to the
>>>>>>> dependencies seems to fix it if you can figure out where the
>>>>>>> out of date
>>>>>>> jars are coming from.
>>>>>>>
>>>>>>> The build is already much closer to a multi-release model than
>>>>>>> a single
>>>>>>> release model.
>>>>>>>
>>>>>>> I've diffed what I have so far and attached it to ARIES-173.
>>>>>>> It includes
>>>>>>> scm info and a lot of version corrections. Due to the failing
>>>>>>> tests I'm not
>>>>>>> too comfortable committing it.
>>>>>>>
>>>>>>> Is anyone else seeing test failures locally?
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>>
>>>>>>>> Hi David,
>>>>>>>>
>>>>>>>> It 'd be great if you are willing to fix these build issues,
>>>>>>>> since you
>>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>>
>>>>>>>> I know the maven release plugin isn't friendly to use some
>>>>>>>> cases, so
>>>>>>>> it is best we get these resolved to make our release process
>>>>>>>> a bit
>>>>>>>> easier.
>>>>>>>>
>>>>>>>> EBA plugin would be a very nice add-on, if it comes in time
>>>>>>>> with the
>>>>>>>> release.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> Lin
>>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <david_jencks@yahoo.com
>>>>>>>> >
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I would like to understand the problems you see better, but
>>>>>>>>>> I do not
>>>>>>>>>> have
>>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>>> explain what
>>>>>>>>>> the
>>>>>>>>>> problems are, why they are problems and the solution at
>>>>>>>>>> some point?
>>>>>>>>>
>>>>>>>>> The biggest immediate problem is that without correct svn
>>>>>>>>> info you can't
>>>>>>>>> do
>>>>>>>>> a release with the release plugin. I'm pretty sure the way
>>>>>>>>> its set up
>>>>>>>>> now,
>>>>>>>>> when you try, the tag will be under maven's apache pom, not
>>>>>>>>> aries.
>>>>>>>>> (you'll
>>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>>> definitely
>>>>>>>>> don't
>>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>>
>>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>>> application,
>>>>>>>>> and samples should always be released in synchrony. Any
>>>>>>>>> time two of
>>>>>>>>> them
>>>>>>>>> happen to be ready for release at the same time it will be
>>>>>>>>> purely
>>>>>>>>> accidental. Right now everyone wants to get a milestone out
>>>>>>>>> the door,
>>>>>>>>> but
>>>>>>>>> looking at the different projects their state of completion
>>>>>>>>> is pretty
>>>>>>>>> much
>>>>>>>>> wildly different. A decision to release all of them at once
>>>>>>>>> is not
>>>>>>>>> based in
>>>>>>>>> any way on them being equally complete. I'm suggesting that
>>>>>>>>> since build
>>>>>>>>> fixes are needed anyway, why not set up a maintainable
>>>>>>>>> structure that
>>>>>>>>> will
>>>>>>>>> continue to work beyond this publicity release. The benefit
>>>>>>>>> to users is
>>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>>> otherwise
>>>>>>>>> the
>>>>>>>>> entire project will never be in a releasable state at once.
>>>>>>>>> (I'm only
>>>>>>>>> exaggerating a little bit :-)
>>>>>>>>>
>>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>>> gyrations that
>>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>>> artifact) out
>>>>>>>>> the
>>>>>>>>> door. This might be ok for one release but (a) I think this
>>>>>>>>> can be done
>>>>>>>>> directly with the assembly plugin short term and (b) an eba-
>>>>>>>>> maven-plugin
>>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>>
>>>>>>>>> I'm willing to fix the build and probably work on an eba
>>>>>>>>> plugin, but
>>>>>>>>> want to
>>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>> Alasdair
>>>>>>>>>>
>>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <david_jencks@yahoo.com
>>>>>>>>>> > wrote:
>>>>>>>>>>
>>>>>>>>>>> This discussion got me worried enough to take a look at
>>>>>>>>>>> the aries
>>>>>>>>>>> build.
>>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>>
>>>>>>>>>>> While it might feel good to try to push out a release as
>>>>>>>>>>> fast as
>>>>>>>>>>> possible
>>>>>>>>>>> I'd prefer to see a sustainable build system in place
>>>>>>>>>>> first. So far
>>>>>>>>>>> it
>>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>>> coupled
>>>>>>>>>>> subprojects. Building them all at once is not going to
>>>>>>>>>>> work for long.
>>>>>>>>>>> I
>>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>>> system now.
>>>>>>>>>>> To me
>>>>>>>>>>> this means:
>>>>>>>>>>>
>>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>>>>> released
>>>>>>>>>>> (mostly
>>>>>>>>>>> svn info) (right now this is completely missing
>>>>>>>>>>> everywhere as far as
>>>>>>>>>>> I can
>>>>>>>>>>> see, which will result in ares getting tagged into svn as
>>>>>>>>>>> part of the
>>>>>>>>>>> apache
>>>>>>>>>>> pom)
>>>>>>>>>>>
>>>>>>>>>>> We can still have a "fake" pom that builds everything, but
>>>>>>>>>>> it won't be
>>>>>>>>>>> part of any release procedure.
>>>>>>>>>>>
>>>>>>>>>>> Having separately released subprojects does not prevent
>>>>>>>>>>> having a
>>>>>>>>>>> single
>>>>>>>>>>> vote on all the releases.
>>>>>>>>>>>
>>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources
>>>>>>>>>>> and
>>>>>>>>>>> filtered-resources to distinguish when filtering is called
>>>>>>>>>>> for.
>>>>>>>>>>>
>>>>>>>>>>> In addition relevant to this particular bit of the thread,
>>>>>>>>>>> we need an
>>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a
>>>>>>>>>>> first release
>>>>>>>>>>> would
>>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>>
>>>>>>>>>>> If there's general agreement I can spend some time playing
>>>>>>>>>>> with the
>>>>>>>>>>> build
>>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>>
>>>>>>>>>>> thoughts?
>>>>>>>>>>>
>>>>>>>>>>> thanks
>>>>>>>>>>> david jencks
>>>>>>>>>>>
>>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'd also like to see us release the sample applications
>>>>>>>>>>>>>> but I think
>>>>>>>>>>>>>> there is
>>>>>>>>>>>>>> at least one complication. Both Blog Sample and
>>>>>>>>>>>>>> AriesTrader
>>>>>>>>>>>>>> generate
>>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>>
>>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly
>>>>>>>>>>>>> module
>>>>>>>>>>>>> wasn't
>>>>>>>>>>>>> being pushed into my local repo. I've made some changes
>>>>>>>>>>>>> to the
>>>>>>>>>>>>> pom.xml
>>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to
>>>>>>>>>>>>> create the .eba
>>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>>> artifact to
>>>>>>>>>>>>> the
>>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>>>>>>>>> the .eba for
>>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>>
>>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do
>>>>>>>>>>>> you know if
>>>>>>>>>>>> it
>>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>>> artifacts
>>>>>>>>>>>> when we do
>>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>>> mechanism for
>>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>>
>>>>>>>>>>>>>> I think the result is that the eba will not be
>>>>>>>>>>>>>> available in a maven
>>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> One of the differences is that AriesTrader first
>>>>>>>>>>>>>> generates a jar
>>>>>>>>>>>>>> using
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba.
>>>>>>>>>>>>>> The jar will
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>>> "application"
>>>>>>>>>>>>>> even
>>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that
>>>>>>>>>>>>>> is correct
>>>>>>>>>>>>>> then
>>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>>> approach
>>>>>>>>>>>>>> for
>>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my
>>>>>>>>>>>>>> equinox
>>>>>>>>>>>>>> assembly
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the
>>>>>>>>>>>>>> individual
>>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>>> approach long
>>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use
>>>>>>>>>>>>> the
>>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact
>>>>>>>>>>>>> from maven
>>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>>
>>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't
>>>>>>>>>>>> work out - is
>>>>>>>>>>>> there anything wrong with the approach I mentioned
>>>>>>>>>>>> earlier of just
>>>>>>>>>>>> using the
>>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the
>>>>>>>>>>>> current
>>>>>>>>>>>> application
>>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>>
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>>> really
>>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>>> The transaction component is functional and we've been
>>>>>>>>>>>>>>> using it
>>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>>> about
>>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <joebohn@gmail.com
>>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ...
>>>>>>>>>>>>>>>> and for
>>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>>> to be the release manager. Your response helps me
>>>>>>>>>>>>>>>> get a better
>>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I was really just interested in the general
>>>>>>>>>>>>>>>> objectives and timing
>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in
>>>>>>>>>>>>>>>> Feb means
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>>>> little too
>>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The more communication the better. It's important to
>>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>>> and planning along the same lines (or understand
>>>>>>>>>>>>>>>> quickly if there
>>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>>> differences of opinion). Knowing that you are
>>>>>>>>>>>>>>>> thinking of
>>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>>> getting more
>>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in
>>>>>>>>>>>>>>>> or out -
>>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> general it doesn't make sense to release things that
>>>>>>>>>>>>>>>> aren't
>>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I
>>>>>>>>>>>>>>>> suspect not all of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday
>>>>>>>>>>>>>>>>> but am now out
>>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to
>>>>>>>>>>>>>>>>> get what we
>>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires.
>>>>>>>>>>>>>>>>> So 'must
>>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each
>>>>>>>>>>>>>>>>> main area of
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>>> unknowns -
>>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in
>>>>>>>>>>>>>>>>> feb. If
>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0
>>>>>>>>>>>>>>>>> to 0.1 and
>>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1
>>>>>>>>>>>>>>>>> to target a
>>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn
>>>>>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding
>>>>>>>>>>>>>>>>>> the release
>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I think it would be good if you could summarize
>>>>>>>>>>>>>>>>>> your thoughts
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep
>>>>>>>>>>>>>>>>>> updated as we
>>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>>> Of particular interest would be the content that we
>>>>>>>>>>>>>>>>>> would like
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> the first release (clarifying what we consider
>>>>>>>>>>>>>>>>>> "must have" from
>>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>>>>> dates for
>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gnodet@gmail.com
>>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any
>>>>>>>>>>>>>>>>>>>> help.
>>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>>> interesting to
>>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one
>>>>>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release
>>>>>>>>>>>>>>>>>>>>> manager.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with
>>>>>>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint
>>>>>>>>>>>>>>>>>>>>>> release as an
>>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache
>>>>>>>>>>>>>>>>>>>>>> release is an
>>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see
>>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>
>>
>> --
>> Joe
>
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
On Mar 2, 2010, at 10:33 AM, Joe Bohn wrote:
> I agree that we should make a global change to 0.1-incubating-
> SNAPSHOT first. Why wouldn't we just do that now?
I started doing some experiments here...
running
mvn versions:set -DnewVersion=0.1-incubating-SNAPSHOT
in root and parent upgrades everything maven knows about just fine.
However there's (1) mentioned below and also a hardcoded version in
two blueprint-itests.
According to
http://wiki.ops4j.org/display/paxexam/Configuration+using+Maven+Plugin
we should be able to replace the hardcoded versions
with .versionAsInProject()
if we run the maven-paxexam-plugin on the project. However I can't get
it to work yet.
>
> Just a heads-up on some other issues related to versions in samples.
> There are two potential problems that I am aware of:
>
> 1) For both Blog-Sample and AriesTrader there are hard-coded
> version references in the Equinox assembly config.ini file which are
> used to specify the bundle jars that are to be started for the
> assembly. Naturally, the versions of the aries bundles in this file
> won't be updated by the maven-release-plugin. I'm not sure of a
> good solution for this beyond just manually changing the config.ini
> files prior to creating a release candidate.
I think we might be able to work around this by putting the config.ini
files in src/main/resources/filtered-resources and defining a bunch of
properties in an appropriate pom and using them for the version
imports of the aries subproject dependencyManagement imports in the
samples root pom. I haven't tried this yet...
>
> 2) I think there is still an unresolved issue related to Blog-
> Sample and how we might be able to demonstrate a bundle upgrade
> scenario. I'm not sure if this capability is included yet in Blog-
> Sample - so it might still be a non-issue at the moment. However,
> we had some discussion on this a week ago or so related to how we
> might be able to include multiple versions of components in the
> sample so that an upgrade scenario could be demonstrated. If that
> is still a goal for the 0.1 release we will need to come up with
> some solution.
no ideas from me on this one :-)
thanks
david jencks
>
> Joe
>
>
> David Jencks wrote:
>> I think everything is ok.... I think (at least with dryRun=true)
>> that the release plugin builds the project first as-is and checks
>> that signing etc works.
>> I added autoVersionSubmodules=true in the root parent pom which
>> will make things work more smoothly :-)
>> I really recommend changing the version to 0.1-incubating-SNAPSHOT
>> first, I'm happy to do this if you want.
>> thanks
>> david jencks
>> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>>> scratch that. I'm working thru this:
>>> http://maven.apache.org/developers/release/apache-release.html as
>>> there's several steps I haven't done.
>>>
>>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>>> I've done most of what I think is needed for aries to be basically
>>>>> releasable. There are some bits left and possibly stuff I've
>>>>> missed.
>>>>>
>>>>> 1. legal file review. There are a bunch of NOTICE files that
>>>>> claim that
>>>>> work from osgi is included. Really? license and notice files
>>>>> are supposed
>>>>> to apply to what is actually in an artifact or checkout. Are
>>>>> some of our
>>>>> source files copied from an osgi source? Also all the legal
>>>>> files that end
>>>>> up in binary artifacts need to be checked. Also we need to run
>>>>> the rat
>>>>> plugin: this should be configured in the default pom. Not sure
>>>>> if I will
>>>>> get to this.
>>>>>
>>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure
>>>>> how to make
>>>>> sure that an eba is working so I didn't mess with this. I think
>>>>> the plugin
>>>>> itself is working well enough to use though.
>>>>>
>>>>> 2. ordering dependencies and dependency management. I find it
>>>>> convenient to
>>>>> have these alphabetized so I can find what I'm looking for, but
>>>>> I haven't
>>>>> done this in most poms. I'm not sure why there isn't a usable
>>>>> tool for
>>>>> doing this but I haven't found one. Dull but useful...
>>>>>
>>>>> 3. It would probably be a really good idea to run mvn
>>>>> dependency:analyze and
>>>>> look carefully at the results. The results from this can require
>>>>> interpretation so its best if someone who is very familiar with
>>>>> how the code
>>>>> works does this.
>>>>>
>>>>> 4. before a release all snapshots need to be resolved to
>>>>> released versions.
>>>>> I don't know if there are any snapshots.
>>>>>
>>>>> To summarize what I've tried to do:
>>>>>
>>>>> 1. default-parent has dependency management for the basic osgi
>>>>> dependencies
>>>>> that all projects are pretty sure to use including the pax stuff
>>>>> used mostly
>>>>> for testing.
>>>>>
>>>>> 2. each subproject has legal files in its checkout root
>>>>>
>>>>> 3. each subproject has an scm element in its pom, but no others
>>>>> do.
>>>>>
>>>>> 4. each subproject has dependency management for everything
>>>>> included in it.
>>>>> In addition, it has its subprojects listed in dependency
>>>>> management. (this
>>>>> is bent slightly for the samples). This means that
>>>>> (a) modules in a subproject don't need to include versions for
>>>>> use of other
>>>>> modules
>>>>> (b) you can get dependency management for all the modules in a
>>>>> subproject
>>>>> by depending on the subproject pom with scope import. (see the
>>>>> samples pom
>>>>> for an example).
>>>>>
>>>>> 5. As a result of (4), modules don't have any versions in any
>>>>> dependency
>>>>> elements.
>>>>>
>>>>> Release is going to involve...
>>>>>
>>>>> releasing the parent
>>>>
>>>> In trunk/parent I tried:
>>>>
>>>> mvn -DdryRun=true release:prepare -Papache-release
>>>>
>>>> Providing 0.1-incubating for the release version
>>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development
>>>> version
>>>>
>>>> then when it builds the 'Top Parent POM' it outputs this:
>>>>
>>>> [INFO] [INFO]
>>>> ------------------------------------------------------------------------
>>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>>> [INFO] [INFO] task-segment: [clean, verify]
>>>> [INFO] [INFO]
>>>> ------------------------------------------------------------------------
>>>> [INFO] [INFO] [clean:clean]
>>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>>> 'false'.
>>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>>> [INFO] [INFO] [site:attach-descriptor]
>>>> [INFO] [INFO] [assembly:single {execution: source-release-
>>>> assembly}]
>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>> skipping
>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>> added, skipping
>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>> added, skipping
>>>> [INFO] [INFO] Building zip:
>>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-
>>>> incubating-SNAPSHOT-source-release.zip
>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>>>> skipping
>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>>>> added, skipping
>>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>>>> added, skipping
>>>> [INFO] [INFO] Preparing source:jar
>>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>>> recursive invocation.
>>>> [INFO] [INFO] No goals needed for project - skipping
>>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>>> classpath-capable package
>>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>>
>>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>>
>>>> Then stops at the gpg stage. I thought it would prompt me for my
>>>> key
>>>> passphrase at this point. Do I need gpg-agent to be running?
>>>>
>>>>> updating the parent version wherever it is used (all subproject
>>>>> parents)
>>>>>
>>>>> releasing the subprojects in an appropriate order and updating
>>>>> their
>>>>> versions wherever they are used.
>>>>>
>>>>> It might be worthwhile changing the pom version to 0.1-
>>>>> incubating-SNAPSHOT
>>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing
>>>>> this because
>>>>> then the versions plugin can be used to update use of a
>>>>> subproject to the
>>>>> newly released version of what it uses. Going from
>>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>>
>>>>> As noted in the "root" pom, don't try to release the root pom
>>>>> and don't try
>>>>> release everything at once from the root pom.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>
>>>>>
>>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>>
>>>>>> I started looking into cleaning up the build, and of course it
>>>>>> is taking
>>>>>> longer than I expected.
>>>>>>
>>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>>
>>>>>> There are some projects in application that stop compiling if you
>>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts
>>>>>> are getting on
>>>>>> the maven classpath before osgi 4.2 artifacts. Adding
>>>>>> exclusions to the
>>>>>> dependencies seems to fix it if you can figure out where the
>>>>>> out of date
>>>>>> jars are coming from.
>>>>>>
>>>>>> The build is already much closer to a multi-release model than
>>>>>> a single
>>>>>> release model.
>>>>>>
>>>>>> I've diffed what I have so far and attached it to ARIES-173.
>>>>>> It includes
>>>>>> scm info and a lot of version corrections. Due to the failing
>>>>>> tests I'm not
>>>>>> too comfortable committing it.
>>>>>>
>>>>>> Is anyone else seeing test failures locally?
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>> It 'd be great if you are willing to fix these build issues,
>>>>>>> since you
>>>>>>> just went through a big release in Geronimo. :)
>>>>>>>
>>>>>>> I know the maven release plugin isn't friendly to use some
>>>>>>> cases, so
>>>>>>> it is best we get these resolved to make our release process a
>>>>>>> bit
>>>>>>> easier.
>>>>>>>
>>>>>>> EBA plugin would be a very nice add-on, if it comes in time
>>>>>>> with the
>>>>>>> release.
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> Lin
>>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <david_jencks@yahoo.com
>>>>>>> >
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I would like to understand the problems you see better, but
>>>>>>>>> I do not
>>>>>>>>> have
>>>>>>>>> the maven background you guys have, any chance you could
>>>>>>>>> explain what
>>>>>>>>> the
>>>>>>>>> problems are, why they are problems and the solution at some
>>>>>>>>> point?
>>>>>>>>
>>>>>>>> The biggest immediate problem is that without correct svn
>>>>>>>> info you can't
>>>>>>>> do
>>>>>>>> a release with the release plugin. I'm pretty sure the way
>>>>>>>> its set up
>>>>>>>> now,
>>>>>>>> when you try, the tag will be under maven's apache pom, not
>>>>>>>> aries.
>>>>>>>> (you'll
>>>>>>>> fail unless you happen to be a maven committer too). You
>>>>>>>> definitely
>>>>>>>> don't
>>>>>>>> want to try to do a release without the release plugin.
>>>>>>>>
>>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>>> application,
>>>>>>>> and samples should always be released in synchrony. Any time
>>>>>>>> two of
>>>>>>>> them
>>>>>>>> happen to be ready for release at the same time it will be
>>>>>>>> purely
>>>>>>>> accidental. Right now everyone wants to get a milestone out
>>>>>>>> the door,
>>>>>>>> but
>>>>>>>> looking at the different projects their state of completion
>>>>>>>> is pretty
>>>>>>>> much
>>>>>>>> wildly different. A decision to release all of them at once
>>>>>>>> is not
>>>>>>>> based in
>>>>>>>> any way on them being equally complete. I'm suggesting that
>>>>>>>> since build
>>>>>>>> fixes are needed anyway, why not set up a maintainable
>>>>>>>> structure that
>>>>>>>> will
>>>>>>>> continue to work beyond this publicity release. The benefit
>>>>>>>> to users is
>>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>>> otherwise
>>>>>>>> the
>>>>>>>> entire project will never be in a releasable state at once.
>>>>>>>> (I'm only
>>>>>>>> exaggerating a little bit :-)
>>>>>>>>
>>>>>>>> What got me looking at this at all is what look like wild
>>>>>>>> gyrations that
>>>>>>>> don't really use maven properly to get an .eba (or some
>>>>>>>> artifact) out
>>>>>>>> the
>>>>>>>> door. This might be ok for one release but (a) I think this
>>>>>>>> can be done
>>>>>>>> directly with the assembly plugin short term and (b) an eba-
>>>>>>>> maven-plugin
>>>>>>>> seems like the obvious more long term solution.
>>>>>>>>
>>>>>>>> I'm willing to fix the build and probably work on an eba
>>>>>>>> plugin, but
>>>>>>>> want to
>>>>>>>> be sure this is ok with everyone first.
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>> Alasdair
>>>>>>>>>
>>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks
>>>>>>>>> <da...@yahoo.com> wrote:
>>>>>>>>>
>>>>>>>>>> This discussion got me worried enough to take a look at the
>>>>>>>>>> aries
>>>>>>>>>> build.
>>>>>>>>>> Now I'm even more worried.
>>>>>>>>>>
>>>>>>>>>> While it might feel good to try to push out a release as
>>>>>>>>>> fast as
>>>>>>>>>> possible
>>>>>>>>>> I'd prefer to see a sustainable build system in place
>>>>>>>>>> first. So far
>>>>>>>>>> it
>>>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>>>> coupled
>>>>>>>>>> subprojects. Building them all at once is not going to
>>>>>>>>>> work for long.
>>>>>>>>>> I
>>>>>>>>>> think we should recognize that and put that in the build
>>>>>>>>>> system now.
>>>>>>>>>> To me
>>>>>>>>>> this means:
>>>>>>>>>>
>>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>>>> released
>>>>>>>>>> (mostly
>>>>>>>>>> svn info) (right now this is completely missing everywhere
>>>>>>>>>> as far as
>>>>>>>>>> I can
>>>>>>>>>> see, which will result in ares getting tagged into svn as
>>>>>>>>>> part of the
>>>>>>>>>> apache
>>>>>>>>>> pom)
>>>>>>>>>>
>>>>>>>>>> We can still have a "fake" pom that builds everything, but
>>>>>>>>>> it won't be
>>>>>>>>>> part of any release procedure.
>>>>>>>>>>
>>>>>>>>>> Having separately released subprojects does not prevent
>>>>>>>>>> having a
>>>>>>>>>> single
>>>>>>>>>> vote on all the releases.
>>>>>>>>>>
>>>>>>>>>> I'd suggest a few other pom tweaks such as using resources
>>>>>>>>>> and
>>>>>>>>>> filtered-resources to distinguish when filtering is called
>>>>>>>>>> for.
>>>>>>>>>>
>>>>>>>>>> In addition relevant to this particular bit of the thread,
>>>>>>>>>> we need an
>>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a
>>>>>>>>>> first release
>>>>>>>>>> would
>>>>>>>>>> be a great idea IMO.
>>>>>>>>>>
>>>>>>>>>> If there's general agreement I can spend some time playing
>>>>>>>>>> with the
>>>>>>>>>> build
>>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>>
>>>>>>>>>> thoughts?
>>>>>>>>>>
>>>>>>>>>> thanks
>>>>>>>>>> david jencks
>>>>>>>>>>
>>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>>
>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd also like to see us release the sample applications
>>>>>>>>>>>>> but I think
>>>>>>>>>>>>> there is
>>>>>>>>>>>>> at least one complication. Both Blog Sample and
>>>>>>>>>>>>> AriesTrader
>>>>>>>>>>>>> generate
>>>>>>>>>>>>> EBAs
>>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>>> to
>>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>>
>>>>>>>>>>>> I realised the .eba file generated in the blog-assembly
>>>>>>>>>>>> module
>>>>>>>>>>>> wasn't
>>>>>>>>>>>> being pushed into my local repo. I've made some changes
>>>>>>>>>>>> to the
>>>>>>>>>>>> pom.xml
>>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create
>>>>>>>>>>>> the .eba
>>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>>> artifact to
>>>>>>>>>>>> the
>>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>>>>>>>> the .eba for
>>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>>
>>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do
>>>>>>>>>>> you know if
>>>>>>>>>>> it
>>>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>>>> artifacts
>>>>>>>>>>> when we do
>>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>>> mechanism for
>>>>>>>>>>> AriesTrader.
>>>>>>>>>>>
>>>>>>>>>>>>> I think the result is that the eba will not be available
>>>>>>>>>>>>> in a maven
>>>>>>>>>>>>> repository.
>>>>>>>>>>>>>
>>>>>>>>>>>>> One of the differences is that AriesTrader first
>>>>>>>>>>>>> generates a jar
>>>>>>>>>>>>> using
>>>>>>>>>>>>> the
>>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba.
>>>>>>>>>>>>> The jar will
>>>>>>>>>>>>> be
>>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>>> "application"
>>>>>>>>>>>>> even
>>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that
>>>>>>>>>>>>> is correct
>>>>>>>>>>>>> then
>>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>>> approach
>>>>>>>>>>>>> for
>>>>>>>>>>>>> the 1st
>>>>>>>>>>>>> release. Unfortunately I haven't actually setup my
>>>>>>>>>>>>> equinox
>>>>>>>>>>>>> assembly
>>>>>>>>>>>>> to
>>>>>>>>>>>>> deploy the eba yet - it still deploys all of the
>>>>>>>>>>>>> individual
>>>>>>>>>>>>> bundles.
>>>>>>>>>>>>
>>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>>>> approach long
>>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use
>>>>>>>>>>>> the
>>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact
>>>>>>>>>>>> from maven
>>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>>
>>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work
>>>>>>>>>>> out - is
>>>>>>>>>>> there anything wrong with the approach I mentioned earlier
>>>>>>>>>>> of just
>>>>>>>>>>> using the
>>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the
>>>>>>>>>>> current
>>>>>>>>>>> application
>>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>>
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>>>> haven't
>>>>>>>>>>>>>> really
>>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>>> The transaction component is functional and we've been
>>>>>>>>>>>>>> using it
>>>>>>>>>>>>>> mostly
>>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>>>> talking
>>>>>>>>>>>>>> about
>>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <joebohn@gmail.com
>>>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ...
>>>>>>>>>>>>>>> and for
>>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>>> to be the release manager. Your response helps me get
>>>>>>>>>>>>>>> a better
>>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I was really just interested in the general objectives
>>>>>>>>>>>>>>> and timing
>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in
>>>>>>>>>>>>>>> Feb means
>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>> be
>>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>>> little too
>>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The more communication the better. It's important to
>>>>>>>>>>>>>>> get
>>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>>> and planning along the same lines (or understand
>>>>>>>>>>>>>>> quickly if there
>>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>>> differences of opinion). Knowing that you are
>>>>>>>>>>>>>>> thinking of
>>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>>> getting more
>>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't have any strong opinions on what should be in
>>>>>>>>>>>>>>> or out -
>>>>>>>>>>>>>>> but
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> general it doesn't make sense to release things that
>>>>>>>>>>>>>>> aren't
>>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>>> At
>>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect
>>>>>>>>>>>>>>> not all of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but
>>>>>>>>>>>>>>>> am now out
>>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to
>>>>>>>>>>>>>>>> get what we
>>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>>> right now in the respectable form the ASF requires.
>>>>>>>>>>>>>>>> So 'must
>>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each
>>>>>>>>>>>>>>>> main area of
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>>>> unknowns -
>>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in
>>>>>>>>>>>>>>>> feb. If
>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>>>> included
>>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0
>>>>>>>>>>>>>>>> to 0.1 and
>>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1
>>>>>>>>>>>>>>>> to target a
>>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn
>>>>>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding
>>>>>>>>>>>>>>>>> the release
>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep
>>>>>>>>>>>>>>>>> updated as we
>>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>>> Of particular interest would be the content that we
>>>>>>>>>>>>>>>>> would like
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>>>> dates for
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gnodet@gmail.com
>>>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any
>>>>>>>>>>>>>>>>>>> help.
>>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>>> interesting to
>>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one
>>>>>>>>>>>>>>>>>> and the
>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release
>>>>>>>>>>>>>>>>>>>> manager.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with
>>>>>>>>>>>>>>>>>>>>> all
>>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release
>>>>>>>>>>>>>>>>>>>>> as an
>>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache
>>>>>>>>>>>>>>>>>>>>> release is an
>>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see
>>>>>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>
>
> --
> Joe
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
I agree that we should make a global change to 0.1-incubating-SNAPSHOT
first. Why wouldn't we just do that now?
Just a heads-up on some other issues related to versions in samples.
There are two potential problems that I am aware of:
1) For both Blog-Sample and AriesTrader there are hard-coded version
references in the Equinox assembly config.ini file which are used to
specify the bundle jars that are to be started for the assembly.
Naturally, the versions of the aries bundles in this file won't be
updated by the maven-release-plugin. I'm not sure of a good solution
for this beyond just manually changing the config.ini files prior to
creating a release candidate.
2) I think there is still an unresolved issue related to Blog-Sample
and how we might be able to demonstrate a bundle upgrade scenario. I'm
not sure if this capability is included yet in Blog-Sample - so it might
still be a non-issue at the moment. However, we had some discussion on
this a week ago or so related to how we might be able to include
multiple versions of components in the sample so that an upgrade
scenario could be demonstrated. If that is still a goal for the 0.1
release we will need to come up with some solution.
Joe
David Jencks wrote:
> I think everything is ok.... I think (at least with dryRun=true) that
> the release plugin builds the project first as-is and checks that
> signing etc works.
>
> I added autoVersionSubmodules=true in the root parent pom which will
> make things work more smoothly :-)
>
> I really recommend changing the version to 0.1-incubating-SNAPSHOT
> first, I'm happy to do this if you want.
>
>
> thanks
> david jencks
>
> On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
>
>> scratch that. I'm working thru this:
>> http://maven.apache.org/developers/release/apache-release.html as
>> there's several steps I haven't done.
>>
>> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>>> I've done most of what I think is needed for aries to be basically
>>>> releasable. There are some bits left and possibly stuff I've missed.
>>>>
>>>> 1. legal file review. There are a bunch of NOTICE files that claim
>>>> that
>>>> work from osgi is included. Really? license and notice files are
>>>> supposed
>>>> to apply to what is actually in an artifact or checkout. Are some
>>>> of our
>>>> source files copied from an osgi source? Also all the legal files
>>>> that end
>>>> up in binary artifacts need to be checked. Also we need to run the rat
>>>> plugin: this should be configured in the default pom. Not sure if I
>>>> will
>>>> get to this.
>>>>
>>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how to
>>>> make
>>>> sure that an eba is working so I didn't mess with this. I think the
>>>> plugin
>>>> itself is working well enough to use though.
>>>>
>>>> 2. ordering dependencies and dependency management. I find it
>>>> convenient to
>>>> have these alphabetized so I can find what I'm looking for, but I
>>>> haven't
>>>> done this in most poms. I'm not sure why there isn't a usable tool for
>>>> doing this but I haven't found one. Dull but useful...
>>>>
>>>> 3. It would probably be a really good idea to run mvn
>>>> dependency:analyze and
>>>> look carefully at the results. The results from this can require
>>>> interpretation so its best if someone who is very familiar with how
>>>> the code
>>>> works does this.
>>>>
>>>> 4. before a release all snapshots need to be resolved to released
>>>> versions.
>>>> I don't know if there are any snapshots.
>>>>
>>>> To summarize what I've tried to do:
>>>>
>>>> 1. default-parent has dependency management for the basic osgi
>>>> dependencies
>>>> that all projects are pretty sure to use including the pax stuff
>>>> used mostly
>>>> for testing.
>>>>
>>>> 2. each subproject has legal files in its checkout root
>>>>
>>>> 3. each subproject has an scm element in its pom, but no others do.
>>>>
>>>> 4. each subproject has dependency management for everything included
>>>> in it.
>>>> In addition, it has its subprojects listed in dependency
>>>> management. (this
>>>> is bent slightly for the samples). This means that
>>>> (a) modules in a subproject don't need to include versions for use
>>>> of other
>>>> modules
>>>> (b) you can get dependency management for all the modules in a
>>>> subproject
>>>> by depending on the subproject pom with scope import. (see the
>>>> samples pom
>>>> for an example).
>>>>
>>>> 5. As a result of (4), modules don't have any versions in any
>>>> dependency
>>>> elements.
>>>>
>>>> Release is going to involve...
>>>>
>>>> releasing the parent
>>>
>>> In trunk/parent I tried:
>>>
>>> mvn -DdryRun=true release:prepare -Papache-release
>>>
>>> Providing 0.1-incubating for the release version
>>> Defaulting to parent-0.1-incubating for the SCM release tag
>>> Defaulting to 0.2-incubating-SNAPSHOT for the new development version
>>>
>>> then when it builds the 'Top Parent POM' it outputs this:
>>>
>>> [INFO] [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] [INFO] Building Aries :: Top Parent POM
>>> [INFO] [INFO] task-segment: [clean, verify]
>>> [INFO] [INFO]
>>> ------------------------------------------------------------------------
>>> [INFO] [INFO] [clean:clean]
>>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>>> 'false'.
>>> [INFO] [INFO] [remote-resources:process {execution: default}]
>>> [INFO] [INFO] [site:attach-descriptor]
>>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added,
>>> skipping
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>> skipping
>>> [INFO] [INFO] Building zip:
>>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
>>>
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added,
>>> skipping
>>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added,
>>> skipping
>>> [INFO] [INFO] Preparing source:jar
>>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>>> recursive invocation.
>>> [INFO] [INFO] No goals needed for project - skipping
>>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>>> classpath-capable package
>>> [INFO] [INFO] [gpg:sign {execution: default}]
>>>
>>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>>
>>> Then stops at the gpg stage. I thought it would prompt me for my key
>>> passphrase at this point. Do I need gpg-agent to be running?
>>>
>>>> updating the parent version wherever it is used (all subproject
>>>> parents)
>>>>
>>>> releasing the subprojects in an appropriate order and updating their
>>>> versions wherever they are used.
>>>>
>>>> It might be worthwhile changing the pom version to
>>>> 0.1-incubating-SNAPSHOT
>>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this
>>>> because
>>>> then the versions plugin can be used to update use of a subproject
>>>> to the
>>>> newly released version of what it uses. Going from
>>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>>
>>>> As noted in the "root" pom, don't try to release the root pom and
>>>> don't try
>>>> release everything at once from the root pom.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>
>>>>
>>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>>
>>>>> I started looking into cleaning up the build, and of course it is
>>>>> taking
>>>>> longer than I expected.
>>>>>
>>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>>
>>>>> There are some projects in application that stop compiling if you
>>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are
>>>>> getting on
>>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions
>>>>> to the
>>>>> dependencies seems to fix it if you can figure out where the out of
>>>>> date
>>>>> jars are coming from.
>>>>>
>>>>> The build is already much closer to a multi-release model than a
>>>>> single
>>>>> release model.
>>>>>
>>>>> I've diffed what I have so far and attached it to ARIES-173. It
>>>>> includes
>>>>> scm info and a lot of version corrections. Due to the failing
>>>>> tests I'm not
>>>>> too comfortable committing it.
>>>>>
>>>>> Is anyone else seeing test failures locally?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> It 'd be great if you are willing to fix these build issues, since
>>>>>> you
>>>>>> just went through a big release in Geronimo. :)
>>>>>>
>>>>>> I know the maven release plugin isn't friendly to use some cases, so
>>>>>> it is best we get these resolved to make our release process a bit
>>>>>> easier.
>>>>>>
>>>>>> EBA plugin would be a very nice add-on, if it comes in time with the
>>>>>> release.
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> Lin
>>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>>>>>> <da...@yahoo.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> I would like to understand the problems you see better, but I do
>>>>>>>> not
>>>>>>>> have
>>>>>>>> the maven background you guys have, any chance you could explain
>>>>>>>> what
>>>>>>>> the
>>>>>>>> problems are, why they are problems and the solution at some point?
>>>>>>>
>>>>>>> The biggest immediate problem is that without correct svn info
>>>>>>> you can't
>>>>>>> do
>>>>>>> a release with the release plugin. I'm pretty sure the way its
>>>>>>> set up
>>>>>>> now,
>>>>>>> when you try, the tag will be under maven's apache pom, not aries.
>>>>>>> (you'll
>>>>>>> fail unless you happen to be a maven committer too). You definitely
>>>>>>> don't
>>>>>>> want to try to do a release without the release plugin.
>>>>>>>
>>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>>> application,
>>>>>>> and samples should always be released in synchrony. Any time two of
>>>>>>> them
>>>>>>> happen to be ready for release at the same time it will be purely
>>>>>>> accidental. Right now everyone wants to get a milestone out the
>>>>>>> door,
>>>>>>> but
>>>>>>> looking at the different projects their state of completion is
>>>>>>> pretty
>>>>>>> much
>>>>>>> wildly different. A decision to release all of them at once is not
>>>>>>> based in
>>>>>>> any way on them being equally complete. I'm suggesting that
>>>>>>> since build
>>>>>>> fixes are needed anyway, why not set up a maintainable structure
>>>>>>> that
>>>>>>> will
>>>>>>> continue to work beyond this publicity release. The benefit to
>>>>>>> users is
>>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>>> otherwise
>>>>>>> the
>>>>>>> entire project will never be in a releasable state at once. (I'm
>>>>>>> only
>>>>>>> exaggerating a little bit :-)
>>>>>>>
>>>>>>> What got me looking at this at all is what look like wild
>>>>>>> gyrations that
>>>>>>> don't really use maven properly to get an .eba (or some artifact)
>>>>>>> out
>>>>>>> the
>>>>>>> door. This might be ok for one release but (a) I think this can
>>>>>>> be done
>>>>>>> directly with the assembly plugin short term and (b) an
>>>>>>> eba-maven-plugin
>>>>>>> seems like the obvious more long term solution.
>>>>>>>
>>>>>>> I'm willing to fix the build and probably work on an eba plugin, but
>>>>>>> want to
>>>>>>> be sure this is ok with everyone first.
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Alasdair
>>>>>>>>
>>>>>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> This discussion got me worried enough to take a look at the aries
>>>>>>>>> build.
>>>>>>>>> Now I'm even more worried.
>>>>>>>>>
>>>>>>>>> While it might feel good to try to push out a release as fast as
>>>>>>>>> possible
>>>>>>>>> I'd prefer to see a sustainable build system in place first.
>>>>>>>>> So far
>>>>>>>>> it
>>>>>>>>> looks to me as if aries is going to be a bunch of loosely coupled
>>>>>>>>> subprojects. Building them all at once is not going to work
>>>>>>>>> for long.
>>>>>>>>> I
>>>>>>>>> think we should recognize that and put that in the build system
>>>>>>>>> now.
>>>>>>>>> To me
>>>>>>>>> this means:
>>>>>>>>>
>>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>>>>>> (mostly
>>>>>>>>> svn info) (right now this is completely missing everywhere as
>>>>>>>>> far as
>>>>>>>>> I can
>>>>>>>>> see, which will result in ares getting tagged into svn as part
>>>>>>>>> of the
>>>>>>>>> apache
>>>>>>>>> pom)
>>>>>>>>>
>>>>>>>>> We can still have a "fake" pom that builds everything, but it
>>>>>>>>> won't be
>>>>>>>>> part of any release procedure.
>>>>>>>>>
>>>>>>>>> Having separately released subprojects does not prevent having a
>>>>>>>>> single
>>>>>>>>> vote on all the releases.
>>>>>>>>>
>>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>>>>>
>>>>>>>>> In addition relevant to this particular bit of the thread, we
>>>>>>>>> need an
>>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>>>>>> release
>>>>>>>>> would
>>>>>>>>> be a great idea IMO.
>>>>>>>>>
>>>>>>>>> If there's general agreement I can spend some time playing with
>>>>>>>>> the
>>>>>>>>> build
>>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>>
>>>>>>>>> thoughts?
>>>>>>>>>
>>>>>>>>> thanks
>>>>>>>>> david jencks
>>>>>>>>>
>>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>>
>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'd also like to see us release the sample applications but
>>>>>>>>>>>> I think
>>>>>>>>>>>> there is
>>>>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>>>>>> generate
>>>>>>>>>>>> EBAs
>>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>>> to
>>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>>
>>>>>>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>>>>>>> wasn't
>>>>>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>>>>>> pom.xml
>>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the
>>>>>>>>>>> .eba
>>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>>> artifact to
>>>>>>>>>>> the
>>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the
>>>>>>>>>>> .eba for
>>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>>
>>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you
>>>>>>>>>> know if
>>>>>>>>>> it
>>>>>>>>>> will work with the maven-release-plugin to push the eba artifacts
>>>>>>>>>> when we do
>>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>>> mechanism for
>>>>>>>>>> AriesTrader.
>>>>>>>>>>
>>>>>>>>>>>> I think the result is that the eba will not be available in
>>>>>>>>>>>> a maven
>>>>>>>>>>>> repository.
>>>>>>>>>>>>
>>>>>>>>>>>> One of the differences is that AriesTrader first generates a
>>>>>>>>>>>> jar
>>>>>>>>>>>> using
>>>>>>>>>>>> the
>>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The
>>>>>>>>>>>> jar will
>>>>>>>>>>>> be
>>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>>> "application"
>>>>>>>>>>>> even
>>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>>>>>> correct
>>>>>>>>>>>> then
>>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>>> approach
>>>>>>>>>>>> for
>>>>>>>>>>>> the 1st
>>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>>> assembly
>>>>>>>>>>>> to
>>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>>> bundles.
>>>>>>>>>>>
>>>>>>>>>>> Using the maven-assembly-plugin likely the preferred approach
>>>>>>>>>>> long
>>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>>>>>>> control and add the .eba one?
>>>>>>>>>>
>>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work out
>>>>>>>>>> - is
>>>>>>>>>> there anything wrong with the approach I mentioned earlier of
>>>>>>>>>> just
>>>>>>>>>> using the
>>>>>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>>>>>> application
>>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>>
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>>> * blueprint
>>>>>>>>>>>>> * jmx
>>>>>>>>>>>>> * jndi
>>>>>>>>>>>>> * transaction
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't think applications are really usable yet and I haven't
>>>>>>>>>>>>> really
>>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>>> The transaction component is functional and we've been
>>>>>>>>>>>>> using it
>>>>>>>>>>>>> mostly
>>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not talking
>>>>>>>>>>>>> about
>>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>>>>>>> better
>>>>>>>>>>>>>> picture
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I was really just interested in the general objectives and
>>>>>>>>>>>>>> timing
>>>>>>>>>>>>>> since
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>>>>>>> means
>>>>>>>>>>>>>> it
>>>>>>>>>>>>>> will
>>>>>>>>>>>>>> be
>>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>>> little too
>>>>>>>>>>>>>> steep to
>>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>>> everybody
>>>>>>>>>>>>>> thinking
>>>>>>>>>>>>>> and planning along the same lines (or understand quickly
>>>>>>>>>>>>>> if there
>>>>>>>>>>>>>> are any
>>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>>>>>> creating
>>>>>>>>>>>>>> a
>>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>>> getting more
>>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I don't have any strong opinions on what should be in or
>>>>>>>>>>>>>> out -
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>>>>>> functional.
>>>>>>>>>>>>>> At
>>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect not
>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am
>>>>>>>>>>>>>>> now out
>>>>>>>>>>>>>>> on
>>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>>> have
>>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main
>>>>>>>>>>>>>>> area of
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> code deserves at least a README to describe what's possible.
>>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>>> this is the first release there are likely a few unknowns -
>>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>> are
>>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>>>>>>>>>> please
>>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to
>>>>>>>>>>>>>>> 0.1 and
>>>>>>>>>>>>>>> target
>>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>>>>>>> target a
>>>>>>>>>>>>>>> new
>>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated
>>>>>>>>>>>>>>>> as we
>>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>>> Of particular interest would be the content that we
>>>>>>>>>>>>>>>> would like
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>> have"), the current status of that content, target dates
>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>>>>>>>>> <gn...@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>>> interesting to
>>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>
>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
I think everything is ok.... I think (at least with dryRun=true) that
the release plugin builds the project first as-is and checks that
signing etc works.
I added autoVersionSubmodules=true in the root parent pom which will
make things work more smoothly :-)
I really recommend changing the version to 0.1-incubating-SNAPSHOT
first, I'm happy to do this if you want.
thanks
david jencks
On Mar 2, 2010, at 9:14 AM, Jeremy Hughes wrote:
> scratch that. I'm working thru this:
> http://maven.apache.org/developers/release/apache-release.html as
> there's several steps I haven't done.
>
> On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
>> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>>> I've done most of what I think is needed for aries to be basically
>>> releasable. There are some bits left and possibly stuff I've
>>> missed.
>>>
>>> 1. legal file review. There are a bunch of NOTICE files that
>>> claim that
>>> work from osgi is included. Really? license and notice files are
>>> supposed
>>> to apply to what is actually in an artifact or checkout. Are some
>>> of our
>>> source files copied from an osgi source? Also all the legal files
>>> that end
>>> up in binary artifacts need to be checked. Also we need to run
>>> the rat
>>> plugin: this should be configured in the default pom. Not sure if
>>> I will
>>> get to this.
>>>
>>> 2. actually using the eba-maven-plugn. I'm not entirely sure how
>>> to make
>>> sure that an eba is working so I didn't mess with this. I think
>>> the plugin
>>> itself is working well enough to use though.
>>>
>>> 2. ordering dependencies and dependency management. I find it
>>> convenient to
>>> have these alphabetized so I can find what I'm looking for, but I
>>> haven't
>>> done this in most poms. I'm not sure why there isn't a usable
>>> tool for
>>> doing this but I haven't found one. Dull but useful...
>>>
>>> 3. It would probably be a really good idea to run mvn
>>> dependency:analyze and
>>> look carefully at the results. The results from this can require
>>> interpretation so its best if someone who is very familiar with
>>> how the code
>>> works does this.
>>>
>>> 4. before a release all snapshots need to be resolved to released
>>> versions.
>>> I don't know if there are any snapshots.
>>>
>>> To summarize what I've tried to do:
>>>
>>> 1. default-parent has dependency management for the basic osgi
>>> dependencies
>>> that all projects are pretty sure to use including the pax stuff
>>> used mostly
>>> for testing.
>>>
>>> 2. each subproject has legal files in its checkout root
>>>
>>> 3. each subproject has an scm element in its pom, but no others do.
>>>
>>> 4. each subproject has dependency management for everything
>>> included in it.
>>> In addition, it has its subprojects listed in dependency
>>> management. (this
>>> is bent slightly for the samples). This means that
>>> (a) modules in a subproject don't need to include versions for
>>> use of other
>>> modules
>>> (b) you can get dependency management for all the modules in a
>>> subproject
>>> by depending on the subproject pom with scope import. (see the
>>> samples pom
>>> for an example).
>>>
>>> 5. As a result of (4), modules don't have any versions in any
>>> dependency
>>> elements.
>>>
>>> Release is going to involve...
>>>
>>> releasing the parent
>>
>> In trunk/parent I tried:
>>
>> mvn -DdryRun=true release:prepare -Papache-release
>>
>> Providing 0.1-incubating for the release version
>> Defaulting to parent-0.1-incubating for the SCM release tag
>> Defaulting to 0.2-incubating-SNAPSHOT for the new development version
>>
>> then when it builds the 'Top Parent POM' it outputs this:
>>
>> [INFO] [INFO]
>> ------------------------------------------------------------------------
>> [INFO] [INFO] Building Aries :: Top Parent POM
>> [INFO] [INFO] task-segment: [clean, verify]
>> [INFO] [INFO]
>> ------------------------------------------------------------------------
>> [INFO] [INFO] [clean:clean]
>> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
>> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
>> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
>> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
>> [INFO] [INFO] Setting property: resource.manager.logwhenfound =>
>> 'false'.
>> [INFO] [INFO] [remote-resources:process {execution: default}]
>> [INFO] [INFO] [site:attach-descriptor]
>> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>> skipping
>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>> added, skipping
>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>> added, skipping
>> [INFO] [INFO] Building zip:
>> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-
>> incubating-SNAPSHOT-source-release.zip
>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added,
>> skipping
>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already
>> added, skipping
>> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already
>> added, skipping
>> [INFO] [INFO] Preparing source:jar
>> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
>> recursive invocation.
>> [INFO] [INFO] No goals needed for project - skipping
>> [INFO] [INFO] [source:jar {execution: attach-sources}]
>> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
>> [INFO] [INFO] Not executing Javadoc as the project is not a Java
>> classpath-capable package
>> [INFO] [INFO] [gpg:sign {execution: default}]
>>
>> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>>
>> Then stops at the gpg stage. I thought it would prompt me for my key
>> passphrase at this point. Do I need gpg-agent to be running?
>>
>>> updating the parent version wherever it is used (all subproject
>>> parents)
>>>
>>> releasing the subprojects in an appropriate order and updating their
>>> versions wherever they are used.
>>>
>>> It might be worthwhile changing the pom version to 0.1-incubating-
>>> SNAPSHOT
>>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this
>>> because
>>> then the versions plugin can be used to update use of a subproject
>>> to the
>>> newly released version of what it uses. Going from
>>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>>
>>> As noted in the "root" pom, don't try to release the root pom and
>>> don't try
>>> release everything at once from the root pom.
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>>
>>>> I started looking into cleaning up the build, and of course it is
>>>> taking
>>>> longer than I expected.
>>>>
>>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>>
>>>> There are some projects in application that stop compiling if you
>>>> alphabetize the dependencies. It looks like osgi 3 artifacts are
>>>> getting on
>>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions
>>>> to the
>>>> dependencies seems to fix it if you can figure out where the out
>>>> of date
>>>> jars are coming from.
>>>>
>>>> The build is already much closer to a multi-release model than a
>>>> single
>>>> release model.
>>>>
>>>> I've diffed what I have so far and attached it to ARIES-173. It
>>>> includes
>>>> scm info and a lot of version corrections. Due to the failing
>>>> tests I'm not
>>>> too comfortable committing it.
>>>>
>>>> Is anyone else seeing test failures locally?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>> It 'd be great if you are willing to fix these build issues,
>>>>> since you
>>>>> just went through a big release in Geronimo. :)
>>>>>
>>>>> I know the maven release plugin isn't friendly to use some
>>>>> cases, so
>>>>> it is best we get these resolved to make our release process a bit
>>>>> easier.
>>>>>
>>>>> EBA plugin would be a very nice add-on, if it comes in time with
>>>>> the
>>>>> release.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Lin
>>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <david_jencks@yahoo.com
>>>>> >
>>>>> wrote:
>>>>>>
>>>>>>> I would like to understand the problems you see better, but I
>>>>>>> do not
>>>>>>> have
>>>>>>> the maven background you guys have, any chance you could
>>>>>>> explain what
>>>>>>> the
>>>>>>> problems are, why they are problems and the solution at some
>>>>>>> point?
>>>>>>
>>>>>> The biggest immediate problem is that without correct svn info
>>>>>> you can't
>>>>>> do
>>>>>> a release with the release plugin. I'm pretty sure the way its
>>>>>> set up
>>>>>> now,
>>>>>> when you try, the tag will be under maven's apache pom, not
>>>>>> aries.
>>>>>> (you'll
>>>>>> fail unless you happen to be a maven committer too). You
>>>>>> definitely
>>>>>> don't
>>>>>> want to try to do a release without the release plugin.
>>>>>>
>>>>>> Organizationally there's no way that for instance blueprint,
>>>>>> application,
>>>>>> and samples should always be released in synchrony. Any time
>>>>>> two of
>>>>>> them
>>>>>> happen to be ready for release at the same time it will be purely
>>>>>> accidental. Right now everyone wants to get a milestone out
>>>>>> the door,
>>>>>> but
>>>>>> looking at the different projects their state of completion is
>>>>>> pretty
>>>>>> much
>>>>>> wildly different. A decision to release all of them at once is
>>>>>> not
>>>>>> based in
>>>>>> any way on them being equally complete. I'm suggesting that
>>>>>> since build
>>>>>> fixes are needed anyway, why not set up a maintainable
>>>>>> structure that
>>>>>> will
>>>>>> continue to work beyond this publicity release. The benefit to
>>>>>> users is
>>>>>> that aries will be able to release bits in a timely fashion;
>>>>>> otherwise
>>>>>> the
>>>>>> entire project will never be in a releasable state at once.
>>>>>> (I'm only
>>>>>> exaggerating a little bit :-)
>>>>>>
>>>>>> What got me looking at this at all is what look like wild
>>>>>> gyrations that
>>>>>> don't really use maven properly to get an .eba (or some
>>>>>> artifact) out
>>>>>> the
>>>>>> door. This might be ok for one release but (a) I think this
>>>>>> can be done
>>>>>> directly with the assembly plugin short term and (b) an eba-
>>>>>> maven-plugin
>>>>>> seems like the obvious more long term solution.
>>>>>>
>>>>>> I'm willing to fix the build and probably work on an eba
>>>>>> plugin, but
>>>>>> want to
>>>>>> be sure this is ok with everyone first.
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Alasdair
>>>>>>>
>>>>>>> On 23 Feb 2010, at 18:18, David Jencks
>>>>>>> <da...@yahoo.com> wrote:
>>>>>>>
>>>>>>>> This discussion got me worried enough to take a look at the
>>>>>>>> aries
>>>>>>>> build.
>>>>>>>> Now I'm even more worried.
>>>>>>>>
>>>>>>>> While it might feel good to try to push out a release as fast
>>>>>>>> as
>>>>>>>> possible
>>>>>>>> I'd prefer to see a sustainable build system in place first.
>>>>>>>> So far
>>>>>>>> it
>>>>>>>> looks to me as if aries is going to be a bunch of loosely
>>>>>>>> coupled
>>>>>>>> subprojects. Building them all at once is not going to work
>>>>>>>> for long.
>>>>>>>> I
>>>>>>>> think we should recognize that and put that in the build
>>>>>>>> system now.
>>>>>>>> To me
>>>>>>>> this means:
>>>>>>>>
>>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>>> 2. each subproject has pom info sufficient so it can be
>>>>>>>> released
>>>>>>>> (mostly
>>>>>>>> svn info) (right now this is completely missing everywhere
>>>>>>>> as far as
>>>>>>>> I can
>>>>>>>> see, which will result in ares getting tagged into svn as
>>>>>>>> part of the
>>>>>>>> apache
>>>>>>>> pom)
>>>>>>>>
>>>>>>>> We can still have a "fake" pom that builds everything, but it
>>>>>>>> won't be
>>>>>>>> part of any release procedure.
>>>>>>>>
>>>>>>>> Having separately released subprojects does not prevent
>>>>>>>> having a
>>>>>>>> single
>>>>>>>> vote on all the releases.
>>>>>>>>
>>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>>>>
>>>>>>>> In addition relevant to this particular bit of the thread, we
>>>>>>>> need an
>>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>>>>> release
>>>>>>>> would
>>>>>>>> be a great idea IMO.
>>>>>>>>
>>>>>>>> If there's general agreement I can spend some time playing
>>>>>>>> with the
>>>>>>>> build
>>>>>>>> and possibly working on the eba plugin.
>>>>>>>>
>>>>>>>> thoughts?
>>>>>>>>
>>>>>>>> thanks
>>>>>>>> david jencks
>>>>>>>>
>>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>>
>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>
>>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I'd also like to see us release the sample applications
>>>>>>>>>>> but I think
>>>>>>>>>>> there is
>>>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>>>>> generate
>>>>>>>>>>> EBAs
>>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>>> to
>>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>>
>>>>>>>>>> I realised the .eba file generated in the blog-assembly
>>>>>>>>>> module
>>>>>>>>>> wasn't
>>>>>>>>>> being pushed into my local repo. I've made some changes to
>>>>>>>>>> the
>>>>>>>>>> pom.xml
>>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create
>>>>>>>>>> the .eba
>>>>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>>>>> artifact to
>>>>>>>>>> the
>>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>>>>>> the .eba for
>>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>>
>>>>>>>>> I've not used the build-helper-maven-plugin before. Do you
>>>>>>>>> know if
>>>>>>>>> it
>>>>>>>>> will work with the maven-release-plugin to push the eba
>>>>>>>>> artifacts
>>>>>>>>> when we do
>>>>>>>>> a release? If so, then I should look at using the same
>>>>>>>>> mechanism for
>>>>>>>>> AriesTrader.
>>>>>>>>>
>>>>>>>>>>> I think the result is that the eba will not be available
>>>>>>>>>>> in a maven
>>>>>>>>>>> repository.
>>>>>>>>>>>
>>>>>>>>>>> One of the differences is that AriesTrader first generates
>>>>>>>>>>> a jar
>>>>>>>>>>> using
>>>>>>>>>>> the
>>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The
>>>>>>>>>>> jar will
>>>>>>>>>>> be
>>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>>> "application"
>>>>>>>>>>> even
>>>>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>>>>> correct
>>>>>>>>>>> then
>>>>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>>>>> approach
>>>>>>>>>>> for
>>>>>>>>>>> the 1st
>>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>>> assembly
>>>>>>>>>>> to
>>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>>> bundles.
>>>>>>>>>>
>>>>>>>>>> Using the maven-assembly-plugin likely the preferred
>>>>>>>>>> approach long
>>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from
>>>>>>>>>> maven
>>>>>>>>>> control and add the .eba one?
>>>>>>>>>
>>>>>>>>> I can give this a try for AriesTrader. If it doesn't work
>>>>>>>>> out - is
>>>>>>>>> there anything wrong with the approach I mentioned earlier
>>>>>>>>> of just
>>>>>>>>> using the
>>>>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>>>>> application
>>>>>>>>> support only look at *.eba archives?
>>>>>>>>>
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>>> * blueprint
>>>>>>>>>>>> * jmx
>>>>>>>>>>>> * jndi
>>>>>>>>>>>> * transaction
>>>>>>>>>>>>
>>>>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>>>>> haven't
>>>>>>>>>>>> really
>>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>>> The transaction component is functional and we've been
>>>>>>>>>>>> using it
>>>>>>>>>>>> mostly
>>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>>>>> talking
>>>>>>>>>>>> about
>>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn
>>>>>>>>>>>> <jo...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks for the response (even while on vacation!) ...
>>>>>>>>>>>>> and for
>>>>>>>>>>>>> volunteering
>>>>>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>>>>>> better
>>>>>>>>>>>>> picture
>>>>>>>>>>>>> of
>>>>>>>>>>>>> the plans.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I was really just interested in the general objectives
>>>>>>>>>>>>> and timing
>>>>>>>>>>>>> since
>>>>>>>>>>>>> it
>>>>>>>>>>>>> hadn't been discussed yet. To get the release out in
>>>>>>>>>>>>> Feb means
>>>>>>>>>>>>> it
>>>>>>>>>>>>> will
>>>>>>>>>>>>> be
>>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a
>>>>>>>>>>>>> little too
>>>>>>>>>>>>> steep to
>>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>>> everybody
>>>>>>>>>>>>> thinking
>>>>>>>>>>>>> and planning along the same lines (or understand quickly
>>>>>>>>>>>>> if there
>>>>>>>>>>>>> are any
>>>>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>>>>> creating
>>>>>>>>>>>>> a
>>>>>>>>>>>>> release candidate next week means that we should be
>>>>>>>>>>>>> getting more
>>>>>>>>>>>>> restrictive
>>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I don't have any strong opinions on what should be in or
>>>>>>>>>>>>> out -
>>>>>>>>>>>>> but
>>>>>>>>>>>>> in
>>>>>>>>>>>>> general it doesn't make sense to release things that
>>>>>>>>>>>>> aren't
>>>>>>>>>>>>> functional.
>>>>>>>>>>>>> At
>>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect
>>>>>>>>>>>>> not all of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>>>>> transaction).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but
>>>>>>>>>>>>>> am now out
>>>>>>>>>>>>>> on
>>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>>>>>> what we
>>>>>>>>>>>>>> have
>>>>>>>>>>>>>> right now in the respectable form the ASF requires. So
>>>>>>>>>>>>>> 'must
>>>>>>>>>>>>>> haves'
>>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>>> distribution
>>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each
>>>>>>>>>>>>>> main area of
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>>>>> possible.
>>>>>>>>>>>>>> Since
>>>>>>>>>>>>>> this is the first release there are likely a few
>>>>>>>>>>>>>> unknowns -
>>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>>> timing I hope/expect to get the release out this in
>>>>>>>>>>>>>> feb. If
>>>>>>>>>>>>>> there
>>>>>>>>>>>>>> are
>>>>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>>>>> included
>>>>>>>>>>>>>> please
>>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to
>>>>>>>>>>>>>> 0.1 and
>>>>>>>>>>>>>> target
>>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>>>>>> target a
>>>>>>>>>>>>>> new
>>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>>>>> release
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>>>>> thoughts
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> an
>>>>>>>>>>>>>>> email
>>>>>>>>>>>>>>> or
>>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated
>>>>>>>>>>>>>>> as we
>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>>> Of particular interest would be the content that we
>>>>>>>>>>>>>>> would like
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> see
>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>>>>> have" from
>>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> have"), the current status of that content, target
>>>>>>>>>>>>>>> dates for
>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>>>>> release.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gnodet@gmail.com
>>>>>>>>>>>>>>>> >
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any
>>>>>>>>>>>>>>>>> help.
>>>>>>>>>>>>>>>>> I guess if you take some notes, it would be
>>>>>>>>>>>>>>>>> interesting to
>>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>>>>> versioning
>>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release
>>>>>>>>>>>>>>>>>>> as an
>>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release
>>>>>>>>>>>>>>>>>>> is an
>>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joe
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
scratch that. I'm working thru this:
http://maven.apache.org/developers/release/apache-release.html as
there's several steps I haven't done.
On 2 March 2010 16:17, Jeremy Hughes <hu...@apache.org> wrote:
> On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
>> I've done most of what I think is needed for aries to be basically
>> releasable. There are some bits left and possibly stuff I've missed.
>>
>> 1. legal file review. There are a bunch of NOTICE files that claim that
>> work from osgi is included. Really? license and notice files are supposed
>> to apply to what is actually in an artifact or checkout. Are some of our
>> source files copied from an osgi source? Also all the legal files that end
>> up in binary artifacts need to be checked. Also we need to run the rat
>> plugin: this should be configured in the default pom. Not sure if I will
>> get to this.
>>
>> 2. actually using the eba-maven-plugn. I'm not entirely sure how to make
>> sure that an eba is working so I didn't mess with this. I think the plugin
>> itself is working well enough to use though.
>>
>> 2. ordering dependencies and dependency management. I find it convenient to
>> have these alphabetized so I can find what I'm looking for, but I haven't
>> done this in most poms. I'm not sure why there isn't a usable tool for
>> doing this but I haven't found one. Dull but useful...
>>
>> 3. It would probably be a really good idea to run mvn dependency:analyze and
>> look carefully at the results. The results from this can require
>> interpretation so its best if someone who is very familiar with how the code
>> works does this.
>>
>> 4. before a release all snapshots need to be resolved to released versions.
>> I don't know if there are any snapshots.
>>
>> To summarize what I've tried to do:
>>
>> 1. default-parent has dependency management for the basic osgi dependencies
>> that all projects are pretty sure to use including the pax stuff used mostly
>> for testing.
>>
>> 2. each subproject has legal files in its checkout root
>>
>> 3. each subproject has an scm element in its pom, but no others do.
>>
>> 4. each subproject has dependency management for everything included in it.
>> In addition, it has its subprojects listed in dependency management. (this
>> is bent slightly for the samples). This means that
>> (a) modules in a subproject don't need to include versions for use of other
>> modules
>> (b) you can get dependency management for all the modules in a subproject
>> by depending on the subproject pom with scope import. (see the samples pom
>> for an example).
>>
>> 5. As a result of (4), modules don't have any versions in any dependency
>> elements.
>>
>> Release is going to involve...
>>
>> releasing the parent
>
> In trunk/parent I tried:
>
> mvn -DdryRun=true release:prepare -Papache-release
>
> Providing 0.1-incubating for the release version
> Defaulting to parent-0.1-incubating for the SCM release tag
> Defaulting to 0.2-incubating-SNAPSHOT for the new development version
>
> then when it builds the 'Top Parent POM' it outputs this:
>
> [INFO] [INFO] ------------------------------------------------------------------------
> [INFO] [INFO] Building Aries :: Top Parent POM
> [INFO] [INFO] task-segment: [clean, verify]
> [INFO] [INFO] ------------------------------------------------------------------------
> [INFO] [INFO] [clean:clean]
> [INFO] [INFO] Setting property: classpath.resource.loader.class =>
> 'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
> [INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
> [INFO] [INFO] Setting property: resource.loader => 'classpath'.
> [INFO] [INFO] Setting property: resource.manager.logwhenfound => 'false'.
> [INFO] [INFO] [remote-resources:process {execution: default}]
> [INFO] [INFO] [site:attach-descriptor]
> [INFO] [INFO] [assembly:single {execution: source-release-assembly}]
> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping
> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added, skipping
> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added, skipping
> [INFO] [INFO] Building zip:
> C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping
> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added, skipping
> [INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added, skipping
> [INFO] [INFO] Preparing source:jar
> [INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
> recursive invocation.
> [INFO] [INFO] No goals needed for project - skipping
> [INFO] [INFO] [source:jar {execution: attach-sources}]
> [INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
> [INFO] [INFO] Not executing Javadoc as the project is not a Java
> classpath-capable package
> [INFO] [INFO] [gpg:sign {execution: default}]
>
> so it seems to be outputting 1.0.0 artifacts still. Any ideas?
>
> Then stops at the gpg stage. I thought it would prompt me for my key
> passphrase at this point. Do I need gpg-agent to be running?
>
>> updating the parent version wherever it is used (all subproject parents)
>>
>> releasing the subprojects in an appropriate order and updating their
>> versions wherever they are used.
>>
>> It might be worthwhile changing the pom version to 0.1-incubating-SNAPSHOT
>> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this because
>> then the versions plugin can be used to update use of a subproject to the
>> newly released version of what it uses. Going from
>> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>>
>> As noted in the "root" pom, don't try to release the root pom and don't try
>> release everything at once from the root pom.
>>
>> thanks
>> david jencks
>>
>>
>>
>> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>>
>>> I started looking into cleaning up the build, and of course it is taking
>>> longer than I expected.
>>>
>>> I'm seriously hampered by failing tests in a fresh checkout.
>>>
>>> There are some projects in application that stop compiling if you
>>> alphabetize the dependencies. It looks like osgi 3 artifacts are getting on
>>> the maven classpath before osgi 4.2 artifacts. Adding exclusions to the
>>> dependencies seems to fix it if you can figure out where the out of date
>>> jars are coming from.
>>>
>>> The build is already much closer to a multi-release model than a single
>>> release model.
>>>
>>> I've diffed what I have so far and attached it to ARIES-173. It includes
>>> scm info and a lot of version corrections. Due to the failing tests I'm not
>>> too comfortable committing it.
>>>
>>> Is anyone else seeing test failures locally?
>>>
>>> thanks
>>> david jencks
>>>
>>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>>
>>>> Hi David,
>>>>
>>>> It 'd be great if you are willing to fix these build issues, since you
>>>> just went through a big release in Geronimo. :)
>>>>
>>>> I know the maven release plugin isn't friendly to use some cases, so
>>>> it is best we get these resolved to make our release process a bit
>>>> easier.
>>>>
>>>> EBA plugin would be a very nice add-on, if it comes in time with the
>>>> release.
>>>>
>>>> Thanks
>>>>
>>>> Lin
>>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>>
>>>>>> I would like to understand the problems you see better, but I do not
>>>>>> have
>>>>>> the maven background you guys have, any chance you could explain what
>>>>>> the
>>>>>> problems are, why they are problems and the solution at some point?
>>>>>
>>>>> The biggest immediate problem is that without correct svn info you can't
>>>>> do
>>>>> a release with the release plugin. I'm pretty sure the way its set up
>>>>> now,
>>>>> when you try, the tag will be under maven's apache pom, not aries.
>>>>> (you'll
>>>>> fail unless you happen to be a maven committer too). You definitely
>>>>> don't
>>>>> want to try to do a release without the release plugin.
>>>>>
>>>>> Organizationally there's no way that for instance blueprint,
>>>>> application,
>>>>> and samples should always be released in synchrony. Any time two of
>>>>> them
>>>>> happen to be ready for release at the same time it will be purely
>>>>> accidental. Right now everyone wants to get a milestone out the door,
>>>>> but
>>>>> looking at the different projects their state of completion is pretty
>>>>> much
>>>>> wildly different. A decision to release all of them at once is not
>>>>> based in
>>>>> any way on them being equally complete. I'm suggesting that since build
>>>>> fixes are needed anyway, why not set up a maintainable structure that
>>>>> will
>>>>> continue to work beyond this publicity release. The benefit to users is
>>>>> that aries will be able to release bits in a timely fashion; otherwise
>>>>> the
>>>>> entire project will never be in a releasable state at once. (I'm only
>>>>> exaggerating a little bit :-)
>>>>>
>>>>> What got me looking at this at all is what look like wild gyrations that
>>>>> don't really use maven properly to get an .eba (or some artifact) out
>>>>> the
>>>>> door. This might be ok for one release but (a) I think this can be done
>>>>> directly with the assembly plugin short term and (b) an eba-maven-plugin
>>>>> seems like the obvious more long term solution.
>>>>>
>>>>> I'm willing to fix the build and probably work on an eba plugin, but
>>>>> want to
>>>>> be sure this is ok with everyone first.
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>>>
>>>>>> Thanks
>>>>>> Alasdair
>>>>>>
>>>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com> wrote:
>>>>>>
>>>>>>> This discussion got me worried enough to take a look at the aries
>>>>>>> build.
>>>>>>> Now I'm even more worried.
>>>>>>>
>>>>>>> While it might feel good to try to push out a release as fast as
>>>>>>> possible
>>>>>>> I'd prefer to see a sustainable build system in place first. So far
>>>>>>> it
>>>>>>> looks to me as if aries is going to be a bunch of loosely coupled
>>>>>>> subprojects. Building them all at once is not going to work for long.
>>>>>>> I
>>>>>>> think we should recognize that and put that in the build system now.
>>>>>>> To me
>>>>>>> this means:
>>>>>>>
>>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>>>> (mostly
>>>>>>> svn info) (right now this is completely missing everywhere as far as
>>>>>>> I can
>>>>>>> see, which will result in ares getting tagged into svn as part of the
>>>>>>> apache
>>>>>>> pom)
>>>>>>>
>>>>>>> We can still have a "fake" pom that builds everything, but it won't be
>>>>>>> part of any release procedure.
>>>>>>>
>>>>>>> Having separately released subprojects does not prevent having a
>>>>>>> single
>>>>>>> vote on all the releases.
>>>>>>>
>>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>>>
>>>>>>> In addition relevant to this particular bit of the thread, we need an
>>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first release
>>>>>>> would
>>>>>>> be a great idea IMO.
>>>>>>>
>>>>>>> If there's general agreement I can spend some time playing with the
>>>>>>> build
>>>>>>> and possibly working on the eba plugin.
>>>>>>>
>>>>>>> thoughts?
>>>>>>>
>>>>>>> thanks
>>>>>>> david jencks
>>>>>>>
>>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>>
>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>
>>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> I'd also like to see us release the sample applications but I think
>>>>>>>>>> there is
>>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>>>> generate
>>>>>>>>>> EBAs
>>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>>> maven-antrun-plugin
>>>>>>>>>> to
>>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>>
>>>>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>>>>> wasn't
>>>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>>>> pom.xml
>>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>>>>>>>>> artifact and the build-helper-maven-plugin to push the artifact to
>>>>>>>>> the
>>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba for
>>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>>
>>>>>>>> I've not used the build-helper-maven-plugin before. Do you know if
>>>>>>>> it
>>>>>>>> will work with the maven-release-plugin to push the eba artifacts
>>>>>>>> when we do
>>>>>>>> a release? If so, then I should look at using the same mechanism for
>>>>>>>> AriesTrader.
>>>>>>>>
>>>>>>>>>> I think the result is that the eba will not be available in a maven
>>>>>>>>>> repository.
>>>>>>>>>>
>>>>>>>>>> One of the differences is that AriesTrader first generates a jar
>>>>>>>>>> using
>>>>>>>>>> the
>>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar will
>>>>>>>>>> be
>>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>>> "application"
>>>>>>>>>> even
>>>>>>>>>> with an extension of "jar" rather than "eba". If that is correct
>>>>>>>>>> then
>>>>>>>>>> perhaps delivery of an application jar is an acceptable approach
>>>>>>>>>> for
>>>>>>>>>> the 1st
>>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>>> assembly
>>>>>>>>>> to
>>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>>> bundles.
>>>>>>>>>
>>>>>>>>> Using the maven-assembly-plugin likely the preferred approach long
>>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>>>>> control and add the .eba one?
>>>>>>>>
>>>>>>>> I can give this a try for AriesTrader. If it doesn't work out - is
>>>>>>>> there anything wrong with the approach I mentioned earlier of just
>>>>>>>> using the
>>>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>>>> application
>>>>>>>> support only look at *.eba archives?
>>>>>>>>
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>>
>>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>>> * blueprint
>>>>>>>>>>> * jmx
>>>>>>>>>>> * jndi
>>>>>>>>>>> * transaction
>>>>>>>>>>>
>>>>>>>>>>> I don't think applications are really usable yet and I haven't
>>>>>>>>>>> really
>>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>>> The transaction component is functional and we've been using it
>>>>>>>>>>> mostly
>>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>>> Do you have any particular concerns with it ? (I'm not talking
>>>>>>>>>>> about
>>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>>>>> volunteering
>>>>>>>>>>>> to be the release manager. Your response helps me get a better
>>>>>>>>>>>> picture
>>>>>>>>>>>> of
>>>>>>>>>>>> the plans.
>>>>>>>>>>>>
>>>>>>>>>>>> I was really just interested in the general objectives and timing
>>>>>>>>>>>> since
>>>>>>>>>>>> it
>>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb means
>>>>>>>>>>>> it
>>>>>>>>>>>> will
>>>>>>>>>>>> be
>>>>>>>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>>>>>>>> steep to
>>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>>
>>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>>> everybody
>>>>>>>>>>>> thinking
>>>>>>>>>>>> and planning along the same lines (or understand quickly if there
>>>>>>>>>>>> are any
>>>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>>>> creating
>>>>>>>>>>>> a
>>>>>>>>>>>> release candidate next week means that we should be getting more
>>>>>>>>>>>> restrictive
>>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>>
>>>>>>>>>>>> I don't have any strong opinions on what should be in or out -
>>>>>>>>>>>> but
>>>>>>>>>>>> in
>>>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>>>> functional.
>>>>>>>>>>>> At
>>>>>>>>>>>> the moment I'm not sure what those are - but I suspect not all of
>>>>>>>>>>>> the
>>>>>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>>>>>
>>>>>>>>>>>> Best Regards,
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out
>>>>>>>>>>>>> on
>>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get what we
>>>>>>>>>>>>> have
>>>>>>>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>>>>>>>> haves'
>>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>>> distribution
>>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main area of
>>>>>>>>>>>>> the
>>>>>>>>>>>>> code deserves at least a README to describe what's possible.
>>>>>>>>>>>>> Since
>>>>>>>>>>>>> this is the first release there are likely a few unknowns -
>>>>>>>>>>>>> w.r.t
>>>>>>>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>>>>>>>> there
>>>>>>>>>>>>> are
>>>>>>>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>>>>>>>> please
>>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>>>>>>>>> target
>>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a
>>>>>>>>>>>>> new
>>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What are your current thoughts and goals regarding the release
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> potential
>>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I think it would be good if you could summarize your thoughts
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> an
>>>>>>>>>>>>>> email
>>>>>>>>>>>>>> or
>>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we
>>>>>>>>>>>>>> make
>>>>>>>>>>>>>> progress.
>>>>>>>>>>>>>> Of particular interest would be the content that we would like
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> see
>>>>>>>>>>>>>> in
>>>>>>>>>>>>>> the first release (clarifying what we consider "must have" from
>>>>>>>>>>>>>> "nice
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> have"), the current status of that content, target dates for
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> release,
>>>>>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting to
>>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>> has
>>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe
>>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
> I've done most of what I think is needed for aries to be basically
> releasable. There are some bits left and possibly stuff I've missed.
>
> 1. legal file review. There are a bunch of NOTICE files that claim that
> work from osgi is included. Really? license and notice files are supposed
> to apply to what is actually in an artifact or checkout. Are some of our
> source files copied from an osgi source? Also all the legal files that end
> up in binary artifacts need to be checked. Also we need to run the rat
> plugin: this should be configured in the default pom. Not sure if I will
> get to this.
>
> 2. actually using the eba-maven-plugn. I'm not entirely sure how to make
> sure that an eba is working so I didn't mess with this. I think the plugin
> itself is working well enough to use though.
>
> 2. ordering dependencies and dependency management. I find it convenient to
> have these alphabetized so I can find what I'm looking for, but I haven't
> done this in most poms. I'm not sure why there isn't a usable tool for
> doing this but I haven't found one. Dull but useful...
>
> 3. It would probably be a really good idea to run mvn dependency:analyze and
> look carefully at the results. The results from this can require
> interpretation so its best if someone who is very familiar with how the code
> works does this.
>
> 4. before a release all snapshots need to be resolved to released versions.
> I don't know if there are any snapshots.
>
> To summarize what I've tried to do:
>
> 1. default-parent has dependency management for the basic osgi dependencies
> that all projects are pretty sure to use including the pax stuff used mostly
> for testing.
>
> 2. each subproject has legal files in its checkout root
>
> 3. each subproject has an scm element in its pom, but no others do.
>
> 4. each subproject has dependency management for everything included in it.
> In addition, it has its subprojects listed in dependency management. (this
> is bent slightly for the samples). This means that
> (a) modules in a subproject don't need to include versions for use of other
> modules
> (b) you can get dependency management for all the modules in a subproject
> by depending on the subproject pom with scope import. (see the samples pom
> for an example).
>
> 5. As a result of (4), modules don't have any versions in any dependency
> elements.
>
> Release is going to involve...
>
> releasing the parent
In trunk/parent I tried:
mvn -DdryRun=true release:prepare -Papache-release
Providing 0.1-incubating for the release version
Defaulting to parent-0.1-incubating for the SCM release tag
Defaulting to 0.2-incubating-SNAPSHOT for the new development version
then when it builds the 'Top Parent POM' it outputs this:
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] Building Aries :: Top Parent POM
[INFO] [INFO] task-segment: [clean, verify]
[INFO] [INFO] ------------------------------------------------------------------------
[INFO] [INFO] [clean:clean]
[INFO] [INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] [INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] [INFO] Setting property: resource.loader => 'classpath'.
[INFO] [INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [INFO] [remote-resources:process {execution: default}]
[INFO] [INFO] [site:attach-descriptor]
[INFO] [INFO] [assembly:single {execution: source-release-assembly}]
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added, skipping
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added, skipping
[INFO] [INFO] Building zip:
C:\cygwin\home\hughesj\oss\aries\trunk\parent\target\parent-1.0.0-incubating-SNAPSHOT-source-release.zip
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/ already added, skipping
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/LICENSE already added, skipping
[INFO] [INFO] parent-1.0.0-incubating-SNAPSHOT/NOTICE already added, skipping
[INFO] [INFO] Preparing source:jar
[INFO] [WARNING] Removing: jar from forked lifecycle, to prevent
recursive invocation.
[INFO] [INFO] No goals needed for project - skipping
[INFO] [INFO] [source:jar {execution: attach-sources}]
[INFO] [INFO] [javadoc:jar {execution: attach-javadocs}]
[INFO] [INFO] Not executing Javadoc as the project is not a Java
classpath-capable package
[INFO] [INFO] [gpg:sign {execution: default}]
so it seems to be outputting 1.0.0 artifacts still. Any ideas?
Then stops at the gpg stage. I thought it would prompt me for my key
passphrase at this point. Do I need gpg-agent to be running?
> updating the parent version wherever it is used (all subproject parents)
>
> releasing the subprojects in an appropriate order and updating their
> versions wherever they are used.
>
> It might be worthwhile changing the pom version to 0.1-incubating-SNAPSHOT
> (or something similar, 0.0-incubating-SNAPSHOT?) before doing this because
> then the versions plugin can be used to update use of a subproject to the
> newly released version of what it uses. Going from
> 1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
>
> As noted in the "root" pom, don't try to release the root pom and don't try
> release everything at once from the root pom.
>
> thanks
> david jencks
>
>
>
> On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
>
>> I started looking into cleaning up the build, and of course it is taking
>> longer than I expected.
>>
>> I'm seriously hampered by failing tests in a fresh checkout.
>>
>> There are some projects in application that stop compiling if you
>> alphabetize the dependencies. It looks like osgi 3 artifacts are getting on
>> the maven classpath before osgi 4.2 artifacts. Adding exclusions to the
>> dependencies seems to fix it if you can figure out where the out of date
>> jars are coming from.
>>
>> The build is already much closer to a multi-release model than a single
>> release model.
>>
>> I've diffed what I have so far and attached it to ARIES-173. It includes
>> scm info and a lot of version corrections. Due to the failing tests I'm not
>> too comfortable committing it.
>>
>> Is anyone else seeing test failures locally?
>>
>> thanks
>> david jencks
>>
>> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>>
>>> Hi David,
>>>
>>> It 'd be great if you are willing to fix these build issues, since you
>>> just went through a big release in Geronimo. :)
>>>
>>> I know the maven release plugin isn't friendly to use some cases, so
>>> it is best we get these resolved to make our release process a bit
>>> easier.
>>>
>>> EBA plugin would be a very nice add-on, if it comes in time with the
>>> release.
>>>
>>> Thanks
>>>
>>> Lin
>>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <da...@yahoo.com>
>>> wrote:
>>>>
>>>>> I would like to understand the problems you see better, but I do not
>>>>> have
>>>>> the maven background you guys have, any chance you could explain what
>>>>> the
>>>>> problems are, why they are problems and the solution at some point?
>>>>
>>>> The biggest immediate problem is that without correct svn info you can't
>>>> do
>>>> a release with the release plugin. I'm pretty sure the way its set up
>>>> now,
>>>> when you try, the tag will be under maven's apache pom, not aries.
>>>> (you'll
>>>> fail unless you happen to be a maven committer too). You definitely
>>>> don't
>>>> want to try to do a release without the release plugin.
>>>>
>>>> Organizationally there's no way that for instance blueprint,
>>>> application,
>>>> and samples should always be released in synchrony. Any time two of
>>>> them
>>>> happen to be ready for release at the same time it will be purely
>>>> accidental. Right now everyone wants to get a milestone out the door,
>>>> but
>>>> looking at the different projects their state of completion is pretty
>>>> much
>>>> wildly different. A decision to release all of them at once is not
>>>> based in
>>>> any way on them being equally complete. I'm suggesting that since build
>>>> fixes are needed anyway, why not set up a maintainable structure that
>>>> will
>>>> continue to work beyond this publicity release. The benefit to users is
>>>> that aries will be able to release bits in a timely fashion; otherwise
>>>> the
>>>> entire project will never be in a releasable state at once. (I'm only
>>>> exaggerating a little bit :-)
>>>>
>>>> What got me looking at this at all is what look like wild gyrations that
>>>> don't really use maven properly to get an .eba (or some artifact) out
>>>> the
>>>> door. This might be ok for one release but (a) I think this can be done
>>>> directly with the assembly plugin short term and (b) an eba-maven-plugin
>>>> seems like the obvious more long term solution.
>>>>
>>>> I'm willing to fix the build and probably work on an eba plugin, but
>>>> want to
>>>> be sure this is ok with everyone first.
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>>>
>>>>> Thanks
>>>>> Alasdair
>>>>>
>>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com> wrote:
>>>>>
>>>>>> This discussion got me worried enough to take a look at the aries
>>>>>> build.
>>>>>> Now I'm even more worried.
>>>>>>
>>>>>> While it might feel good to try to push out a release as fast as
>>>>>> possible
>>>>>> I'd prefer to see a sustainable build system in place first. So far
>>>>>> it
>>>>>> looks to me as if aries is going to be a bunch of loosely coupled
>>>>>> subprojects. Building them all at once is not going to work for long.
>>>>>> I
>>>>>> think we should recognize that and put that in the build system now.
>>>>>> To me
>>>>>> this means:
>>>>>>
>>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>>> (mostly
>>>>>> svn info) (right now this is completely missing everywhere as far as
>>>>>> I can
>>>>>> see, which will result in ares getting tagged into svn as part of the
>>>>>> apache
>>>>>> pom)
>>>>>>
>>>>>> We can still have a "fake" pom that builds everything, but it won't be
>>>>>> part of any release procedure.
>>>>>>
>>>>>> Having separately released subprojects does not prevent having a
>>>>>> single
>>>>>> vote on all the releases.
>>>>>>
>>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>>
>>>>>> In addition relevant to this particular bit of the thread, we need an
>>>>>> eba-maven-plugin to assemble ebas. Getting this into a first release
>>>>>> would
>>>>>> be a great idea IMO.
>>>>>>
>>>>>> If there's general agreement I can spend some time playing with the
>>>>>> build
>>>>>> and possibly working on the eba plugin.
>>>>>>
>>>>>> thoughts?
>>>>>>
>>>>>> thanks
>>>>>> david jencks
>>>>>>
>>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>>
>>>>>>> Jeremy Hughes wrote:
>>>>>>>>
>>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> I'd also like to see us release the sample applications but I think
>>>>>>>>> there is
>>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>>> generate
>>>>>>>>> EBAs
>>>>>>>>> using different techniques - but both leverage the
>>>>>>>>> maven-antrun-plugin
>>>>>>>>> to
>>>>>>>>> finally produce a file of type "eba".
>>>>>>>>
>>>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>>>> wasn't
>>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>>> pom.xml
>>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>>>>>>>> artifact and the build-helper-maven-plugin to push the artifact to
>>>>>>>> the
>>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba for
>>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>>
>>>>>>> I've not used the build-helper-maven-plugin before. Do you know if
>>>>>>> it
>>>>>>> will work with the maven-release-plugin to push the eba artifacts
>>>>>>> when we do
>>>>>>> a release? If so, then I should look at using the same mechanism for
>>>>>>> AriesTrader.
>>>>>>>
>>>>>>>>> I think the result is that the eba will not be available in a maven
>>>>>>>>> repository.
>>>>>>>>>
>>>>>>>>> One of the differences is that AriesTrader first generates a jar
>>>>>>>>> using
>>>>>>>>> the
>>>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar will
>>>>>>>>> be
>>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>>> "application"
>>>>>>>>> even
>>>>>>>>> with an extension of "jar" rather than "eba". If that is correct
>>>>>>>>> then
>>>>>>>>> perhaps delivery of an application jar is an acceptable approach
>>>>>>>>> for
>>>>>>>>> the 1st
>>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>>> assembly
>>>>>>>>> to
>>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>>> bundles.
>>>>>>>>
>>>>>>>> Using the maven-assembly-plugin likely the preferred approach long
>>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>>>> control and add the .eba one?
>>>>>>>
>>>>>>> I can give this a try for AriesTrader. If it doesn't work out - is
>>>>>>> there anything wrong with the approach I mentioned earlier of just
>>>>>>> using the
>>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>>> application
>>>>>>> support only look at *.eba archives?
>>>>>>>
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>>
>>>>>>>>>> I'd like to see at least those included:
>>>>>>>>>> * blueprint
>>>>>>>>>> * jmx
>>>>>>>>>> * jndi
>>>>>>>>>> * transaction
>>>>>>>>>>
>>>>>>>>>> I don't think applications are really usable yet and I haven't
>>>>>>>>>> really
>>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>>> The transaction component is functional and we've been using it
>>>>>>>>>> mostly
>>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>>> Do you have any particular concerns with it ? (I'm not talking
>>>>>>>>>> about
>>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>>
>>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>>>> volunteering
>>>>>>>>>>> to be the release manager. Your response helps me get a better
>>>>>>>>>>> picture
>>>>>>>>>>> of
>>>>>>>>>>> the plans.
>>>>>>>>>>>
>>>>>>>>>>> I was really just interested in the general objectives and timing
>>>>>>>>>>> since
>>>>>>>>>>> it
>>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb means
>>>>>>>>>>> it
>>>>>>>>>>> will
>>>>>>>>>>> be
>>>>>>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>>>>>>> steep to
>>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>>
>>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>>> everybody
>>>>>>>>>>> thinking
>>>>>>>>>>> and planning along the same lines (or understand quickly if there
>>>>>>>>>>> are any
>>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>>> creating
>>>>>>>>>>> a
>>>>>>>>>>> release candidate next week means that we should be getting more
>>>>>>>>>>> restrictive
>>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>>
>>>>>>>>>>> I don't have any strong opinions on what should be in or out -
>>>>>>>>>>> but
>>>>>>>>>>> in
>>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>>> functional.
>>>>>>>>>>> At
>>>>>>>>>>> the moment I'm not sure what those are - but I suspect not all of
>>>>>>>>>>> the
>>>>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>>>>
>>>>>>>>>>> Best Regards,
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out
>>>>>>>>>>>> on
>>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>>
>>>>>>>>>>>> Personally, I think the 0.1 release should serve to get what we
>>>>>>>>>>>> have
>>>>>>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>>>>>>> haves'
>>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>>> distribution
>>>>>>>>>>>> files that are acceptable to the IPMC. I think each main area of
>>>>>>>>>>>> the
>>>>>>>>>>>> code deserves at least a README to describe what's possible.
>>>>>>>>>>>> Since
>>>>>>>>>>>> this is the first release there are likely a few unknowns -
>>>>>>>>>>>> w.r.t
>>>>>>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>>>>>>> there
>>>>>>>>>>>> are
>>>>>>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>>>>>>> please
>>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>>>>>>>> target
>>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a
>>>>>>>>>>>> new
>>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>>
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>
>>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>>
>>>>>>>>>>>>> What are your current thoughts and goals regarding the release
>>>>>>>>>>>>> and
>>>>>>>>>>>>> potential
>>>>>>>>>>>>> target dates?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I think it would be good if you could summarize your thoughts
>>>>>>>>>>>>> in
>>>>>>>>>>>>> an
>>>>>>>>>>>>> email
>>>>>>>>>>>>> or
>>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we
>>>>>>>>>>>>> make
>>>>>>>>>>>>> progress.
>>>>>>>>>>>>> Of particular interest would be the content that we would like
>>>>>>>>>>>>> to
>>>>>>>>>>>>> see
>>>>>>>>>>>>> in
>>>>>>>>>>>>> the first release (clarifying what we consider "must have" from
>>>>>>>>>>>>> "nice
>>>>>>>>>>>>> to
>>>>>>>>>>>>> have"), the current status of that content, target dates for
>>>>>>>>>>>>> the
>>>>>>>>>>>>> release,
>>>>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting to
>>>>>>>>>>>>>>> put
>>>>>>>>>>>>>>> those
>>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>>>> process
>>>>>>>>>>>>>> has
>>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Joe
>>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joe
>>>>>>
>>>>
>>>>
>>
>
>
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 2 March 2010 02:28, David Jencks <da...@yahoo.com> wrote:
> I've done most of what I think is needed for aries to be basically
> releasable. There are some bits left and possibly stuff I've missed.
>
> 1. legal file review. There are a bunch of NOTICE files that claim that
> work from osgi is included. Really? license and notice files are supposed
> to apply to what is actually in an artifact or checkout. Are some of our
> source files copied from an osgi source? Also all the legal files that end
> up in binary artifacts need to be checked. Also we need to run the rat
> plugin: this should be configured in the default pom. Not sure if I will
> get to this.
I just tried it in blueprint/ - it complains at 2 unknown licenses.
Perhaps OSGi is one. I'll investigate tomorrow.
Cheers,
Jeremy
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
David Jencks wrote:
> I started looking into cleaning up the build, and of course it is taking
> longer than I expected.
>
> I'm seriously hampered by failing tests in a fresh checkout.
>
> There are some projects in application that stop compiling if you
> alphabetize the dependencies. It looks like osgi 3 artifacts are
> getting on the maven classpath before osgi 4.2 artifacts. Adding
> exclusions to the dependencies seems to fix it if you can figure out
> where the out of date jars are coming from.
>
> The build is already much closer to a multi-release model than a single
> release model.
>
> I've diffed what I have so far and attached it to ARIES-173. It
> includes scm info and a lot of version corrections. Due to the failing
> tests I'm not too comfortable committing it.
>
> Is anyone else seeing test failures locally?
I occasionally see a build failure due to failing tests (usually
blueprint) and the rerun the build and it will pass. As of yesterday
with r916084 everything was building fine for me locally.
Joe
>
> thanks
> david jencks
>
> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>
>> Hi David,
>>
>> It 'd be great if you are willing to fix these build issues, since you
>> just went through a big release in Geronimo. :)
>>
>> I know the maven release plugin isn't friendly to use some cases, so
>> it is best we get these resolved to make our release process a bit
>> easier.
>>
>> EBA plugin would be a very nice add-on, if it comes in time with the
>> release.
>>
>> Thanks
>>
>> Lin
>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <da...@yahoo.com>
>> wrote:
>>>
>>>> I would like to understand the problems you see better, but I do not
>>>> have
>>>> the maven background you guys have, any chance you could explain
>>>> what the
>>>> problems are, why they are problems and the solution at some point?
>>>
>>> The biggest immediate problem is that without correct svn info you
>>> can't do
>>> a release with the release plugin. I'm pretty sure the way its set
>>> up now,
>>> when you try, the tag will be under maven's apache pom, not aries.
>>> (you'll
>>> fail unless you happen to be a maven committer too). You definitely
>>> don't
>>> want to try to do a release without the release plugin.
>>>
>>> Organizationally there's no way that for instance blueprint,
>>> application,
>>> and samples should always be released in synchrony. Any time two of
>>> them
>>> happen to be ready for release at the same time it will be purely
>>> accidental. Right now everyone wants to get a milestone out the
>>> door, but
>>> looking at the different projects their state of completion is pretty
>>> much
>>> wildly different. A decision to release all of them at once is not
>>> based in
>>> any way on them being equally complete. I'm suggesting that since build
>>> fixes are needed anyway, why not set up a maintainable structure that
>>> will
>>> continue to work beyond this publicity release. The benefit to users is
>>> that aries will be able to release bits in a timely fashion;
>>> otherwise the
>>> entire project will never be in a releasable state at once. (I'm only
>>> exaggerating a little bit :-)
>>>
>>> What got me looking at this at all is what look like wild gyrations that
>>> don't really use maven properly to get an .eba (or some artifact) out
>>> the
>>> door. This might be ok for one release but (a) I think this can be done
>>> directly with the assembly plugin short term and (b) an eba-maven-plugin
>>> seems like the obvious more long term solution.
>>>
>>> I'm willing to fix the build and probably work on an eba plugin, but
>>> want to
>>> be sure this is ok with everyone first.
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Thanks
>>>> Alasdair
>>>>
>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com> wrote:
>>>>
>>>>> This discussion got me worried enough to take a look at the aries
>>>>> build.
>>>>> Now I'm even more worried.
>>>>>
>>>>> While it might feel good to try to push out a release as fast as
>>>>> possible
>>>>> I'd prefer to see a sustainable build system in place first. So
>>>>> far it
>>>>> looks to me as if aries is going to be a bunch of loosely coupled
>>>>> subprojects. Building them all at once is not going to work for
>>>>> long. I
>>>>> think we should recognize that and put that in the build system
>>>>> now. To me
>>>>> this means:
>>>>>
>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>> (mostly
>>>>> svn info) (right now this is completely missing everywhere as far
>>>>> as I can
>>>>> see, which will result in ares getting tagged into svn as part of
>>>>> the apache
>>>>> pom)
>>>>>
>>>>> We can still have a "fake" pom that builds everything, but it won't be
>>>>> part of any release procedure.
>>>>>
>>>>> Having separately released subprojects does not prevent having a
>>>>> single
>>>>> vote on all the releases.
>>>>>
>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>
>>>>> In addition relevant to this particular bit of the thread, we need an
>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>> release would
>>>>> be a great idea IMO.
>>>>>
>>>>> If there's general agreement I can spend some time playing with the
>>>>> build
>>>>> and possibly working on the eba plugin.
>>>>>
>>>>> thoughts?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>>
>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I'd also like to see us release the sample applications but I think
>>>>>>>> there is
>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>> generate
>>>>>>>> EBAs
>>>>>>>> using different techniques - but both leverage the
>>>>>>>> maven-antrun-plugin
>>>>>>>> to
>>>>>>>> finally produce a file of type "eba".
>>>>>>>
>>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>>> wasn't
>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>> pom.xml
>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>>>>>>> artifact and the build-helper-maven-plugin to push the artifact
>>>>>>> to the
>>>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba for
>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>
>>>>>> I've not used the build-helper-maven-plugin before. Do you know
>>>>>> if it
>>>>>> will work with the maven-release-plugin to push the eba artifacts
>>>>>> when we do
>>>>>> a release? If so, then I should look at using the same mechanism for
>>>>>> AriesTrader.
>>>>>>
>>>>>>>> I think the result is that the eba will not be available in a maven
>>>>>>>> repository.
>>>>>>>>
>>>>>>>> One of the differences is that AriesTrader first generates a jar
>>>>>>>> using
>>>>>>>> the
>>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar
>>>>>>>> will be
>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>> "application"
>>>>>>>> even
>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>> correct then
>>>>>>>> perhaps delivery of an application jar is an acceptable approach
>>>>>>>> for
>>>>>>>> the 1st
>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>> assembly
>>>>>>>> to
>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>> bundles.
>>>>>>>
>>>>>>> Using the maven-assembly-plugin likely the preferred approach long
>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>>> control and add the .eba one?
>>>>>>
>>>>>> I can give this a try for AriesTrader. If it doesn't work out - is
>>>>>> there anything wrong with the approach I mentioned earlier of just
>>>>>> using the
>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>> application
>>>>>> support only look at *.eba archives?
>>>>>>
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>
>>>>>>>>> I'd like to see at least those included:
>>>>>>>>> * blueprint
>>>>>>>>> * jmx
>>>>>>>>> * jndi
>>>>>>>>> * transaction
>>>>>>>>>
>>>>>>>>> I don't think applications are really usable yet and I haven't
>>>>>>>>> really
>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>> The transaction component is functional and we've been using it
>>>>>>>>> mostly
>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>> Do you have any particular concerns with it ? (I'm not talking
>>>>>>>>> about
>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>
>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>>> volunteering
>>>>>>>>>> to be the release manager. Your response helps me get a better
>>>>>>>>>> picture
>>>>>>>>>> of
>>>>>>>>>> the plans.
>>>>>>>>>>
>>>>>>>>>> I was really just interested in the general objectives and timing
>>>>>>>>>> since
>>>>>>>>>> it
>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>>> means it
>>>>>>>>>> will
>>>>>>>>>> be
>>>>>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>>>>>> steep to
>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>
>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>> everybody
>>>>>>>>>> thinking
>>>>>>>>>> and planning along the same lines (or understand quickly if there
>>>>>>>>>> are any
>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>> creating
>>>>>>>>>> a
>>>>>>>>>> release candidate next week means that we should be getting more
>>>>>>>>>> restrictive
>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>
>>>>>>>>>> I don't have any strong opinions on what should be in or out -
>>>>>>>>>> but
>>>>>>>>>> in
>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>> functional.
>>>>>>>>>> At
>>>>>>>>>> the moment I'm not sure what those are - but I suspect not all of
>>>>>>>>>> the
>>>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now
>>>>>>>>>>> out on
>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>
>>>>>>>>>>> Personally, I think the 0.1 release should serve to get what we
>>>>>>>>>>> have
>>>>>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>>>>>> haves'
>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>> distribution
>>>>>>>>>>> files that are acceptable to the IPMC. I think each main area of
>>>>>>>>>>> the
>>>>>>>>>>> code deserves at least a README to describe what's possible.
>>>>>>>>>>> Since
>>>>>>>>>>> this is the first release there are likely a few unknowns -
>>>>>>>>>>> w.r.t
>>>>>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>>>>>> there
>>>>>>>>>>> are
>>>>>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>>>>>> please
>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>>>>>>> target
>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target
>>>>>>>>>>> a new
>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Jeremy
>>>>>>>>>>>
>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>
>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>> release and
>>>>>>>>>>>> potential
>>>>>>>>>>>> target dates?
>>>>>>>>>>>>
>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>> thoughts in
>>>>>>>>>>>> an
>>>>>>>>>>>> email
>>>>>>>>>>>> or
>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we
>>>>>>>>>>>> make
>>>>>>>>>>>> progress.
>>>>>>>>>>>> Of particular interest would be the content that we would
>>>>>>>>>>>> like to
>>>>>>>>>>>> see
>>>>>>>>>>>> in
>>>>>>>>>>>> the first release (clarifying what we consider "must have" from
>>>>>>>>>>>> "nice
>>>>>>>>>>>> to
>>>>>>>>>>>> have"), the current status of that content, target dates for
>>>>>>>>>>>> the
>>>>>>>>>>>> release,
>>>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting to
>>>>>>>>>>>>>> put
>>>>>>>>>>>>>> those
>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>>> process
>>>>>>>>>>>>> has
>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>
>>>
>>>
>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
I've done most of what I think is needed for aries to be basically
releasable. There are some bits left and possibly stuff I've missed.
1. legal file review. There are a bunch of NOTICE files that claim
that work from osgi is included. Really? license and notice files
are supposed to apply to what is actually in an artifact or checkout.
Are some of our source files copied from an osgi source? Also all the
legal files that end up in binary artifacts need to be checked. Also
we need to run the rat plugin: this should be configured in the
default pom. Not sure if I will get to this.
2. actually using the eba-maven-plugn. I'm not entirely sure how to
make sure that an eba is working so I didn't mess with this. I think
the plugin itself is working well enough to use though.
2. ordering dependencies and dependency management. I find it
convenient to have these alphabetized so I can find what I'm looking
for, but I haven't done this in most poms. I'm not sure why there
isn't a usable tool for doing this but I haven't found one. Dull but
useful...
3. It would probably be a really good idea to run mvn
dependency:analyze and look carefully at the results. The results
from this can require interpretation so its best if someone who is
very familiar with how the code works does this.
4. before a release all snapshots need to be resolved to released
versions. I don't know if there are any snapshots.
To summarize what I've tried to do:
1. default-parent has dependency management for the basic osgi
dependencies that all projects are pretty sure to use including the
pax stuff used mostly for testing.
2. each subproject has legal files in its checkout root
3. each subproject has an scm element in its pom, but no others do.
4. each subproject has dependency management for everything included
in it. In addition, it has its subprojects listed in dependency
management. (this is bent slightly for the samples). This means that
(a) modules in a subproject don't need to include versions for use
of other modules
(b) you can get dependency management for all the modules in a
subproject by depending on the subproject pom with scope import. (see
the samples pom for an example).
5. As a result of (4), modules don't have any versions in any
dependency elements.
Release is going to involve...
releasing the parent
updating the parent version wherever it is used (all subproject parents)
releasing the subprojects in an appropriate order and updating their
versions wherever they are used.
It might be worthwhile changing the pom version to 0.1-incubating-
SNAPSHOT (or something similar, 0.0-incubating-SNAPSHOT?) before doing
this because then the versions plugin can be used to update use of a
subproject to the newly released version of what it uses. Going from
1.0.0-incubating-SNAPSHOT to 0.1-incubating won't allow this.
As noted in the "root" pom, don't try to release the root pom and
don't try release everything at once from the root pom.
thanks
david jencks
On Feb 24, 2010, at 11:55 PM, David Jencks wrote:
> I started looking into cleaning up the build, and of course it is
> taking longer than I expected.
>
> I'm seriously hampered by failing tests in a fresh checkout.
>
> There are some projects in application that stop compiling if you
> alphabetize the dependencies. It looks like osgi 3 artifacts are
> getting on the maven classpath before osgi 4.2 artifacts. Adding
> exclusions to the dependencies seems to fix it if you can figure out
> where the out of date jars are coming from.
>
> The build is already much closer to a multi-release model than a
> single release model.
>
> I've diffed what I have so far and attached it to ARIES-173. It
> includes scm info and a lot of version corrections. Due to the
> failing tests I'm not too comfortable committing it.
>
> Is anyone else seeing test failures locally?
>
> thanks
> david jencks
>
> On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
>
>> Hi David,
>>
>> It 'd be great if you are willing to fix these build issues, since
>> you
>> just went through a big release in Geronimo. :)
>>
>> I know the maven release plugin isn't friendly to use some cases, so
>> it is best we get these resolved to make our release process a bit
>> easier.
>>
>> EBA plugin would be a very nice add-on, if it comes in time with
>> the release.
>>
>> Thanks
>>
>> Lin
>> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
>> <da...@yahoo.com> wrote:
>>>
>>>> I would like to understand the problems you see better, but I do
>>>> not have
>>>> the maven background you guys have, any chance you could explain
>>>> what the
>>>> problems are, why they are problems and the solution at some point?
>>>
>>> The biggest immediate problem is that without correct svn info you
>>> can't do
>>> a release with the release plugin. I'm pretty sure the way its
>>> set up now,
>>> when you try, the tag will be under maven's apache pom, not
>>> aries. (you'll
>>> fail unless you happen to be a maven committer too). You
>>> definitely don't
>>> want to try to do a release without the release plugin.
>>>
>>> Organizationally there's no way that for instance blueprint,
>>> application,
>>> and samples should always be released in synchrony. Any time two
>>> of them
>>> happen to be ready for release at the same time it will be purely
>>> accidental. Right now everyone wants to get a milestone out the
>>> door, but
>>> looking at the different projects their state of completion is
>>> pretty much
>>> wildly different. A decision to release all of them at once is
>>> not based in
>>> any way on them being equally complete. I'm suggesting that since
>>> build
>>> fixes are needed anyway, why not set up a maintainable structure
>>> that will
>>> continue to work beyond this publicity release. The benefit to
>>> users is
>>> that aries will be able to release bits in a timely fashion;
>>> otherwise the
>>> entire project will never be in a releasable state at once. (I'm
>>> only
>>> exaggerating a little bit :-)
>>>
>>> What got me looking at this at all is what look like wild
>>> gyrations that
>>> don't really use maven properly to get an .eba (or some artifact)
>>> out the
>>> door. This might be ok for one release but (a) I think this can
>>> be done
>>> directly with the assembly plugin short term and (b) an eba-maven-
>>> plugin
>>> seems like the obvious more long term solution.
>>>
>>> I'm willing to fix the build and probably work on an eba plugin,
>>> but want to
>>> be sure this is ok with everyone first.
>>>
>>> thanks
>>> david jencks
>>>
>>>>
>>>> Thanks
>>>> Alasdair
>>>>
>>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com>
>>>> wrote:
>>>>
>>>>> This discussion got me worried enough to take a look at the
>>>>> aries build.
>>>>> Now I'm even more worried.
>>>>>
>>>>> While it might feel good to try to push out a release as fast as
>>>>> possible
>>>>> I'd prefer to see a sustainable build system in place first. So
>>>>> far it
>>>>> looks to me as if aries is going to be a bunch of loosely coupled
>>>>> subprojects. Building them all at once is not going to work for
>>>>> long. I
>>>>> think we should recognize that and put that in the build system
>>>>> now. To me
>>>>> this means:
>>>>>
>>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>>> 2. each subproject has pom info sufficient so it can be released
>>>>> (mostly
>>>>> svn info) (right now this is completely missing everywhere as
>>>>> far as I can
>>>>> see, which will result in ares getting tagged into svn as part
>>>>> of the apache
>>>>> pom)
>>>>>
>>>>> We can still have a "fake" pom that builds everything, but it
>>>>> won't be
>>>>> part of any release procedure.
>>>>>
>>>>> Having separately released subprojects does not prevent having a
>>>>> single
>>>>> vote on all the releases.
>>>>>
>>>>> I'd suggest a few other pom tweaks such as using resources and
>>>>> filtered-resources to distinguish when filtering is called for.
>>>>>
>>>>> In addition relevant to this particular bit of the thread, we
>>>>> need an
>>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>>> release would
>>>>> be a great idea IMO.
>>>>>
>>>>> If there's general agreement I can spend some time playing with
>>>>> the build
>>>>> and possibly working on the eba plugin.
>>>>>
>>>>> thoughts?
>>>>>
>>>>> thanks
>>>>> david jencks
>>>>>
>>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>>
>>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> I'd also like to see us release the sample applications but I
>>>>>>>> think
>>>>>>>> there is
>>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>>> generate
>>>>>>>> EBAs
>>>>>>>> using different techniques - but both leverage the maven-
>>>>>>>> antrun-plugin
>>>>>>>> to
>>>>>>>> finally produce a file of type "eba".
>>>>>>>
>>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>>> wasn't
>>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>>> pom.xml
>>>>>>> in ARIES-198 to fix this. So now it uses antrun to create
>>>>>>> the .eba
>>>>>>> artifact and the build-helper-maven-plugin to push the
>>>>>>> artifact to the
>>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>>> the .eba for
>>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>>
>>>>>> I've not used the build-helper-maven-plugin before. Do you
>>>>>> know if it
>>>>>> will work with the maven-release-plugin to push the eba
>>>>>> artifacts when we do
>>>>>> a release? If so, then I should look at using the same
>>>>>> mechanism for
>>>>>> AriesTrader.
>>>>>>
>>>>>>>> I think the result is that the eba will not be available in a
>>>>>>>> maven
>>>>>>>> repository.
>>>>>>>>
>>>>>>>> One of the differences is that AriesTrader first generates a
>>>>>>>> jar using
>>>>>>>> the
>>>>>>>> maven-assembly-plugin and then copies this to an eba. The
>>>>>>>> jar will be
>>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>>> "application"
>>>>>>>> even
>>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>>> correct then
>>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>>> approach for
>>>>>>>> the 1st
>>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>>> assembly
>>>>>>>> to
>>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>>> bundles.
>>>>>>>
>>>>>>> Using the maven-assembly-plugin likely the preferred approach
>>>>>>> long
>>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>>> control and add the .eba one?
>>>>>>
>>>>>> I can give this a try for AriesTrader. If it doesn't work out
>>>>>> - is
>>>>>> there anything wrong with the approach I mentioned earlier of
>>>>>> just using the
>>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>>> application
>>>>>> support only look at *.eba archives?
>>>>>>
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Guillaume Nodet wrote:
>>>>>>>>>
>>>>>>>>> I'd like to see at least those included:
>>>>>>>>> * blueprint
>>>>>>>>> * jmx
>>>>>>>>> * jndi
>>>>>>>>> * transaction
>>>>>>>>>
>>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>>> haven't really
>>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>>> The transaction component is functional and we've been using
>>>>>>>>> it
>>>>>>>>> mostly
>>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>>> talking about
>>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>>
>>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>>> volunteering
>>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>>> better
>>>>>>>>>> picture
>>>>>>>>>> of
>>>>>>>>>> the plans.
>>>>>>>>>>
>>>>>>>>>> I was really just interested in the general objectives and
>>>>>>>>>> timing
>>>>>>>>>> since
>>>>>>>>>> it
>>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>>> means it
>>>>>>>>>> will
>>>>>>>>>> be
>>>>>>>>>> delivered next week. I'm afraid the hill might be a little
>>>>>>>>>> too
>>>>>>>>>> steep to
>>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>>
>>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>>> everybody
>>>>>>>>>> thinking
>>>>>>>>>> and planning along the same lines (or understand quickly if
>>>>>>>>>> there
>>>>>>>>>> are any
>>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>>> creating
>>>>>>>>>> a
>>>>>>>>>> release candidate next week means that we should be getting
>>>>>>>>>> more
>>>>>>>>>> restrictive
>>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>>
>>>>>>>>>> I don't have any strong opinions on what should be in or
>>>>>>>>>> out - but
>>>>>>>>>> in
>>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>>> functional.
>>>>>>>>>> At
>>>>>>>>>> the moment I'm not sure what those are - but I suspect not
>>>>>>>>>> all of
>>>>>>>>>> the
>>>>>>>>>> components are fully functional yet (for example
>>>>>>>>>> transaction).
>>>>>>>>>>
>>>>>>>>>> Best Regards,
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am
>>>>>>>>>>> now out on
>>>>>>>>>>> vacation until monday.
>>>>>>>>>>>
>>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>>> what we
>>>>>>>>>>> have
>>>>>>>>>>> right now in the respectable form the ASF requires. So
>>>>>>>>>>> 'must haves'
>>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>>> distribution
>>>>>>>>>>> files that are acceptable to the IPMC. I think each main
>>>>>>>>>>> area of
>>>>>>>>>>> the
>>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>>> possible. Since
>>>>>>>>>>> this is the first release there are likely a few unknowns
>>>>>>>>>>> - w.r.t
>>>>>>>>>>> timing I hope/expect to get the release out this in feb.
>>>>>>>>>>> If there
>>>>>>>>>>> are
>>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>>> included please
>>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to
>>>>>>>>>>> 0.1 and
>>>>>>>>>>> target
>>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>>> target a new
>>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Jeremy
>>>>>>>>>>>
>>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy,
>>>>>>>>>>>>
>>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>>> release and
>>>>>>>>>>>> potential
>>>>>>>>>>>> target dates?
>>>>>>>>>>>>
>>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>>> thoughts in
>>>>>>>>>>>> an
>>>>>>>>>>>> email
>>>>>>>>>>>> or
>>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as
>>>>>>>>>>>> we make
>>>>>>>>>>>> progress.
>>>>>>>>>>>> Of particular interest would be the content that we would
>>>>>>>>>>>> like to
>>>>>>>>>>>> see
>>>>>>>>>>>> in
>>>>>>>>>>>> the first release (clarifying what we consider "must
>>>>>>>>>>>> have" from
>>>>>>>>>>>> "nice
>>>>>>>>>>>> to
>>>>>>>>>>>> have"), the current status of that content, target dates
>>>>>>>>>>>> for the
>>>>>>>>>>>> release,
>>>>>>>>>>>> and the process that we plan to use to generate the
>>>>>>>>>>>> release.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gnodet@gmail.com
>>>>>>>>>>>>> >
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>>> I guess if you take some notes, it would be interesting
>>>>>>>>>>>>>> to put
>>>>>>>>>>>>>> those
>>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Certainly will. It's been a while since I did one and
>>>>>>>>>>>>> the process
>>>>>>>>>>>>> has
>>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>>> version number. Best to start with a simple
>>>>>>>>>>>>>>>> versioning scheme,
>>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as
>>>>>>>>>>>>>>>> an issue.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Joe
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe
>>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>
>>>
>>>
>
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
I started looking into cleaning up the build, and of course it is
taking longer than I expected.
I'm seriously hampered by failing tests in a fresh checkout.
There are some projects in application that stop compiling if you
alphabetize the dependencies. It looks like osgi 3 artifacts are
getting on the maven classpath before osgi 4.2 artifacts. Adding
exclusions to the dependencies seems to fix it if you can figure out
where the out of date jars are coming from.
The build is already much closer to a multi-release model than a
single release model.
I've diffed what I have so far and attached it to ARIES-173. It
includes scm info and a lot of version corrections. Due to the
failing tests I'm not too comfortable committing it.
Is anyone else seeing test failures locally?
thanks
david jencks
On Feb 24, 2010, at 1:50 PM, Lin Sun wrote:
> Hi David,
>
> It 'd be great if you are willing to fix these build issues, since you
> just went through a big release in Geronimo. :)
>
> I know the maven release plugin isn't friendly to use some cases, so
> it is best we get these resolved to make our release process a bit
> easier.
>
> EBA plugin would be a very nice add-on, if it comes in time with the
> release.
>
> Thanks
>
> Lin
> On Tue, Feb 23, 2010 at 8:56 PM, David Jencks
> <da...@yahoo.com> wrote:
>>
>>> I would like to understand the problems you see better, but I do
>>> not have
>>> the maven background you guys have, any chance you could explain
>>> what the
>>> problems are, why they are problems and the solution at some point?
>>
>> The biggest immediate problem is that without correct svn info you
>> can't do
>> a release with the release plugin. I'm pretty sure the way its set
>> up now,
>> when you try, the tag will be under maven's apache pom, not aries.
>> (you'll
>> fail unless you happen to be a maven committer too). You definitely
>> don't
>> want to try to do a release without the release plugin.
>>
>> Organizationally there's no way that for instance blueprint,
>> application,
>> and samples should always be released in synchrony. Any time two
>> of them
>> happen to be ready for release at the same time it will be purely
>> accidental. Right now everyone wants to get a milestone out the
>> door, but
>> looking at the different projects their state of completion is
>> pretty much
>> wildly different. A decision to release all of them at once is not
>> based in
>> any way on them being equally complete. I'm suggesting that since
>> build
>> fixes are needed anyway, why not set up a maintainable structure
>> that will
>> continue to work beyond this publicity release. The benefit to
>> users is
>> that aries will be able to release bits in a timely fashion;
>> otherwise the
>> entire project will never be in a releasable state at once. (I'm only
>> exaggerating a little bit :-)
>>
>> What got me looking at this at all is what look like wild gyrations
>> that
>> don't really use maven properly to get an .eba (or some artifact)
>> out the
>> door. This might be ok for one release but (a) I think this can be
>> done
>> directly with the assembly plugin short term and (b) an eba-maven-
>> plugin
>> seems like the obvious more long term solution.
>>
>> I'm willing to fix the build and probably work on an eba plugin,
>> but want to
>> be sure this is ok with everyone first.
>>
>> thanks
>> david jencks
>>
>>>
>>> Thanks
>>> Alasdair
>>>
>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com>
>>> wrote:
>>>
>>>> This discussion got me worried enough to take a look at the aries
>>>> build.
>>>> Now I'm even more worried.
>>>>
>>>> While it might feel good to try to push out a release as fast as
>>>> possible
>>>> I'd prefer to see a sustainable build system in place first. So
>>>> far it
>>>> looks to me as if aries is going to be a bunch of loosely coupled
>>>> subprojects. Building them all at once is not going to work for
>>>> long. I
>>>> think we should recognize that and put that in the build system
>>>> now. To me
>>>> this means:
>>>>
>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>> 2. each subproject has pom info sufficient so it can be released
>>>> (mostly
>>>> svn info) (right now this is completely missing everywhere as
>>>> far as I can
>>>> see, which will result in ares getting tagged into svn as part of
>>>> the apache
>>>> pom)
>>>>
>>>> We can still have a "fake" pom that builds everything, but it
>>>> won't be
>>>> part of any release procedure.
>>>>
>>>> Having separately released subprojects does not prevent having a
>>>> single
>>>> vote on all the releases.
>>>>
>>>> I'd suggest a few other pom tweaks such as using resources and
>>>> filtered-resources to distinguish when filtering is called for.
>>>>
>>>> In addition relevant to this particular bit of the thread, we
>>>> need an
>>>> eba-maven-plugin to assemble ebas. Getting this into a first
>>>> release would
>>>> be a great idea IMO.
>>>>
>>>> If there's general agreement I can spend some time playing with
>>>> the build
>>>> and possibly working on the eba plugin.
>>>>
>>>> thoughts?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>
>>>>> Jeremy Hughes wrote:
>>>>>>
>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>
>>>>>>> I'd also like to see us release the sample applications but I
>>>>>>> think
>>>>>>> there is
>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>> generate
>>>>>>> EBAs
>>>>>>> using different techniques - but both leverage the maven-
>>>>>>> antrun-plugin
>>>>>>> to
>>>>>>> finally produce a file of type "eba".
>>>>>>
>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>> wasn't
>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>> pom.xml
>>>>>> in ARIES-198 to fix this. So now it uses antrun to create
>>>>>> the .eba
>>>>>> artifact and the build-helper-maven-plugin to push the artifact
>>>>>> to the
>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>> the .eba for
>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>
>>>>> I've not used the build-helper-maven-plugin before. Do you know
>>>>> if it
>>>>> will work with the maven-release-plugin to push the eba
>>>>> artifacts when we do
>>>>> a release? If so, then I should look at using the same
>>>>> mechanism for
>>>>> AriesTrader.
>>>>>
>>>>>>> I think the result is that the eba will not be available in a
>>>>>>> maven
>>>>>>> repository.
>>>>>>>
>>>>>>> One of the differences is that AriesTrader first generates a
>>>>>>> jar using
>>>>>>> the
>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar
>>>>>>> will be
>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>> "application"
>>>>>>> even
>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>> correct then
>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>> approach for
>>>>>>> the 1st
>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>> assembly
>>>>>>> to
>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>> bundles.
>>>>>>
>>>>>> Using the maven-assembly-plugin likely the preferred approach
>>>>>> long
>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>> control and add the .eba one?
>>>>>
>>>>> I can give this a try for AriesTrader. If it doesn't work out -
>>>>> is
>>>>> there anything wrong with the approach I mentioned earlier of
>>>>> just using the
>>>>> jar artifacts rather than the eba artifacts? Will the current
>>>>> application
>>>>> support only look at *.eba archives?
>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Guillaume Nodet wrote:
>>>>>>>>
>>>>>>>> I'd like to see at least those included:
>>>>>>>> * blueprint
>>>>>>>> * jmx
>>>>>>>> * jndi
>>>>>>>> * transaction
>>>>>>>>
>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>> haven't really
>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>> The transaction component is functional and we've been using it
>>>>>>>> mostly
>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>> talking about
>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>
>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>> volunteering
>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>> better
>>>>>>>>> picture
>>>>>>>>> of
>>>>>>>>> the plans.
>>>>>>>>>
>>>>>>>>> I was really just interested in the general objectives and
>>>>>>>>> timing
>>>>>>>>> since
>>>>>>>>> it
>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>> means it
>>>>>>>>> will
>>>>>>>>> be
>>>>>>>>> delivered next week. I'm afraid the hill might be a little
>>>>>>>>> too
>>>>>>>>> steep to
>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>
>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>> everybody
>>>>>>>>> thinking
>>>>>>>>> and planning along the same lines (or understand quickly if
>>>>>>>>> there
>>>>>>>>> are any
>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>> creating
>>>>>>>>> a
>>>>>>>>> release candidate next week means that we should be getting
>>>>>>>>> more
>>>>>>>>> restrictive
>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>
>>>>>>>>> I don't have any strong opinions on what should be in or out
>>>>>>>>> - but
>>>>>>>>> in
>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>> functional.
>>>>>>>>> At
>>>>>>>>> the moment I'm not sure what those are - but I suspect not
>>>>>>>>> all of
>>>>>>>>> the
>>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am
>>>>>>>>>> now out on
>>>>>>>>>> vacation until monday.
>>>>>>>>>>
>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>> what we
>>>>>>>>>> have
>>>>>>>>>> right now in the respectable form the ASF requires. So
>>>>>>>>>> 'must haves'
>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>> distribution
>>>>>>>>>> files that are acceptable to the IPMC. I think each main
>>>>>>>>>> area of
>>>>>>>>>> the
>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>> possible. Since
>>>>>>>>>> this is the first release there are likely a few unknowns -
>>>>>>>>>> w.r.t
>>>>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>>>>> there
>>>>>>>>>> are
>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>> included please
>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1
>>>>>>>>>> and
>>>>>>>>>> target
>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>> target a new
>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Jeremy
>>>>>>>>>>
>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Jeremy,
>>>>>>>>>>>
>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>> release and
>>>>>>>>>>> potential
>>>>>>>>>>> target dates?
>>>>>>>>>>>
>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>> thoughts in
>>>>>>>>>>> an
>>>>>>>>>>> email
>>>>>>>>>>> or
>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as
>>>>>>>>>>> we make
>>>>>>>>>>> progress.
>>>>>>>>>>> Of particular interest would be the content that we would
>>>>>>>>>>> like to
>>>>>>>>>>> see
>>>>>>>>>>> in
>>>>>>>>>>> the first release (clarifying what we consider "must have"
>>>>>>>>>>> from
>>>>>>>>>>> "nice
>>>>>>>>>>> to
>>>>>>>>>>> have"), the current status of that content, target dates
>>>>>>>>>>> for the
>>>>>>>>>>> release,
>>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gnodet@gmail.com
>>>>>>>>>>>> >
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>> I guess if you take some notes, it would be interesting
>>>>>>>>>>>>> to put
>>>>>>>>>>>>> those
>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>>
>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>> process
>>>>>>>>>>>> has
>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>> components
>>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>> scheme,
>>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>>> important
>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joe
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Joe
>>>>
>>
>>
Re: [DISCUSSION] Aries release
Posted by Lin Sun <li...@gmail.com>.
Hi David,
It 'd be great if you are willing to fix these build issues, since you
just went through a big release in Geronimo. :)
I know the maven release plugin isn't friendly to use some cases, so
it is best we get these resolved to make our release process a bit
easier.
EBA plugin would be a very nice add-on, if it comes in time with the release.
Thanks
Lin
On Tue, Feb 23, 2010 at 8:56 PM, David Jencks <da...@yahoo.com> wrote:
>
>> I would like to understand the problems you see better, but I do not have
>> the maven background you guys have, any chance you could explain what the
>> problems are, why they are problems and the solution at some point?
>
> The biggest immediate problem is that without correct svn info you can't do
> a release with the release plugin. I'm pretty sure the way its set up now,
> when you try, the tag will be under maven's apache pom, not aries. (you'll
> fail unless you happen to be a maven committer too). You definitely don't
> want to try to do a release without the release plugin.
>
> Organizationally there's no way that for instance blueprint, application,
> and samples should always be released in synchrony. Any time two of them
> happen to be ready for release at the same time it will be purely
> accidental. Right now everyone wants to get a milestone out the door, but
> looking at the different projects their state of completion is pretty much
> wildly different. A decision to release all of them at once is not based in
> any way on them being equally complete. I'm suggesting that since build
> fixes are needed anyway, why not set up a maintainable structure that will
> continue to work beyond this publicity release. The benefit to users is
> that aries will be able to release bits in a timely fashion; otherwise the
> entire project will never be in a releasable state at once. (I'm only
> exaggerating a little bit :-)
>
> What got me looking at this at all is what look like wild gyrations that
> don't really use maven properly to get an .eba (or some artifact) out the
> door. This might be ok for one release but (a) I think this can be done
> directly with the assembly plugin short term and (b) an eba-maven-plugin
> seems like the obvious more long term solution.
>
> I'm willing to fix the build and probably work on an eba plugin, but want to
> be sure this is ok with everyone first.
>
> thanks
> david jencks
>
>>
>> Thanks
>> Alasdair
>>
>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com> wrote:
>>
>>> This discussion got me worried enough to take a look at the aries build.
>>> Now I'm even more worried.
>>>
>>> While it might feel good to try to push out a release as fast as possible
>>> I'd prefer to see a sustainable build system in place first. So far it
>>> looks to me as if aries is going to be a bunch of loosely coupled
>>> subprojects. Building them all at once is not going to work for long. I
>>> think we should recognize that and put that in the build system now. To me
>>> this means:
>>>
>>> 1. a parent pom that isn't at the root of the svn trunk.
>>> 2. each subproject has pom info sufficient so it can be released (mostly
>>> svn info) (right now this is completely missing everywhere as far as I can
>>> see, which will result in ares getting tagged into svn as part of the apache
>>> pom)
>>>
>>> We can still have a "fake" pom that builds everything, but it won't be
>>> part of any release procedure.
>>>
>>> Having separately released subprojects does not prevent having a single
>>> vote on all the releases.
>>>
>>> I'd suggest a few other pom tweaks such as using resources and
>>> filtered-resources to distinguish when filtering is called for.
>>>
>>> In addition relevant to this particular bit of the thread, we need an
>>> eba-maven-plugin to assemble ebas. Getting this into a first release would
>>> be a great idea IMO.
>>>
>>> If there's general agreement I can spend some time playing with the build
>>> and possibly working on the eba plugin.
>>>
>>> thoughts?
>>>
>>> thanks
>>> david jencks
>>>
>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>
>>>> Jeremy Hughes wrote:
>>>>>
>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>
>>>>>> I'd also like to see us release the sample applications but I think
>>>>>> there is
>>>>>> at least one complication. Both Blog Sample and AriesTrader generate
>>>>>> EBAs
>>>>>> using different techniques - but both leverage the maven-antrun-plugin
>>>>>> to
>>>>>> finally produce a file of type "eba".
>>>>>
>>>>> I realised the .eba file generated in the blog-assembly module wasn't
>>>>> being pushed into my local repo. I've made some changes to the pom.xml
>>>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>>>>> artifact and the build-helper-maven-plugin to push the artifact to the
>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba for
>>>>> the ianal plugin in the verify phase to succeed.
>>>>
>>>> I've not used the build-helper-maven-plugin before. Do you know if it
>>>> will work with the maven-release-plugin to push the eba artifacts when we do
>>>> a release? If so, then I should look at using the same mechanism for
>>>> AriesTrader.
>>>>
>>>>>> I think the result is that the eba will not be available in a maven
>>>>>> repository.
>>>>>>
>>>>>> One of the differences is that AriesTrader first generates a jar using
>>>>>> the
>>>>>> maven-assembly-plugin and then copies this to an eba. The jar will be
>>>>>> managed by maven and IIUC it should be deployable as an "application"
>>>>>> even
>>>>>> with an extension of "jar" rather than "eba". If that is correct then
>>>>>> perhaps delivery of an application jar is an acceptable approach for
>>>>>> the 1st
>>>>>> release. Unfortunately I haven't actually setup my equinox assembly
>>>>>> to
>>>>>> deploy the eba yet - it still deploys all of the individual bundles.
>>>>>
>>>>> Using the maven-assembly-plugin likely the preferred approach long
>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>> control and add the .eba one?
>>>>
>>>> I can give this a try for AriesTrader. If it doesn't work out - is
>>>> there anything wrong with the approach I mentioned earlier of just using the
>>>> jar artifacts rather than the eba artifacts? Will the current application
>>>> support only look at *.eba archives?
>>>>
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>>
>>>>>>> I'd like to see at least those included:
>>>>>>> * blueprint
>>>>>>> * jmx
>>>>>>> * jndi
>>>>>>> * transaction
>>>>>>>
>>>>>>> I don't think applications are really usable yet and I haven't really
>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>> The transaction component is functional and we've been using it
>>>>>>> mostly
>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>> Do you have any particular concerns with it ? (I'm not talking about
>>>>>>> declarative transactions for blueprint, note).
>>>>>>>
>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>> volunteering
>>>>>>>> to be the release manager. Your response helps me get a better
>>>>>>>> picture
>>>>>>>> of
>>>>>>>> the plans.
>>>>>>>>
>>>>>>>> I was really just interested in the general objectives and timing
>>>>>>>> since
>>>>>>>> it
>>>>>>>> hadn't been discussed yet. To get the release out in Feb means it
>>>>>>>> will
>>>>>>>> be
>>>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>>>> steep to
>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>
>>>>>>>> The more communication the better. It's important to get everybody
>>>>>>>> thinking
>>>>>>>> and planning along the same lines (or understand quickly if there
>>>>>>>> are any
>>>>>>>> differences of opinion). Knowing that you are thinking of creating
>>>>>>>> a
>>>>>>>> release candidate next week means that we should be getting more
>>>>>>>> restrictive
>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>
>>>>>>>> I don't have any strong opinions on what should be in or out - but
>>>>>>>> in
>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>> functional.
>>>>>>>> At
>>>>>>>> the moment I'm not sure what those are - but I suspect not all of
>>>>>>>> the
>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>
>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>>>>>> vacation until monday.
>>>>>>>>>
>>>>>>>>> Personally, I think the 0.1 release should serve to get what we
>>>>>>>>> have
>>>>>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>>>>>> are to get the build in the right shape to create the distribution
>>>>>>>>> files that are acceptable to the IPMC. I think each main area of
>>>>>>>>> the
>>>>>>>>> code deserves at least a README to describe what's possible. Since
>>>>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>>>>> timing I hope/expect to get the release out this in feb. If there
>>>>>>>>> are
>>>>>>>>> particular JIRAs or other issues you feel should be included please
>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>>>>> target
>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Jeremy
>>>>>>>>>
>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>>
>>>>>>>>>> Jeremy,
>>>>>>>>>>
>>>>>>>>>> What are your current thoughts and goals regarding the release and
>>>>>>>>>> potential
>>>>>>>>>> target dates?
>>>>>>>>>>
>>>>>>>>>> I think it would be good if you could summarize your thoughts in
>>>>>>>>>> an
>>>>>>>>>> email
>>>>>>>>>> or
>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>>>>>> progress.
>>>>>>>>>> Of particular interest would be the content that we would like to
>>>>>>>>>> see
>>>>>>>>>> in
>>>>>>>>>> the first release (clarifying what we consider "must have" from
>>>>>>>>>> "nice
>>>>>>>>>> to
>>>>>>>>>> have"), the current status of that content, target dates for the
>>>>>>>>>> release,
>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>
>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>> I guess if you take some notes, it would be interesting to put
>>>>>>>>>>>> those
>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>
>>>>>>>>>>> Certainly will. It's been a while since I did one and the process
>>>>>>>>>>> has
>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sounds like the consensus is for a release with all components
>>>>>>>>>>>>>> at a
>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>> version number. Best to start with a simple versioning scheme,
>>>>>>>>>>>>>> IMO.
>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>> important
>>>>>>>>>>>>>> step
>>>>>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>> ------------------------
>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>> ------------------------
>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>>
>>>>
>>>> --
>>>> Joe
>>>
>
>
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
On Feb 23, 2010, at 7:44 PM, Joe Bohn wrote:
> David Jencks wrote:
>> On Feb 23, 2010, at 5:13 PM, Alasdair Nottingham wrote:
>>> I'm am new to maven, so sorry if I show my ignorance.
>>>
>>> While I think I can see the value to what you suggest moving
>>> forward if we choose to release sub-projects independantly (I say
>>> if because we haven't discussed or agreed what tbd long term
>>> answer is yet) I do not understand the benefit to a user of Aries
>>> of this change.
>>>
>>> As a result it does not appear to me to be key to resolve prior to
>>> release.
>>>
>>> I would like to understand the problems you see better, but I do
>>> not have the maven background you guys have, any chance you could
>>> explain what the problems are, why they are problems and the
>>> solution at some point?
>> The biggest immediate problem is that without correct svn info you
>> can't do a release with the release plugin. I'm pretty sure the
>> way its set up now, when you try, the tag will be under maven's
>> apache pom, not aries. (you'll fail unless you happen to be a
>> maven committer too). You definitely don't want to try to do a
>> release without the release plugin.
>> Organizationally there's no way that for instance blueprint,
>> application, and samples should always be released in synchrony.
>> Any time two of them happen to be ready for release at the same
>> time it will be purely accidental. Right now everyone wants to get
>> a milestone out the door, but looking at the different projects
>> their state of completion is pretty much wildly different. A
>> decision to release all of them at once is not based in any way on
>> them being equally complete. I'm suggesting that since build fixes
>> are needed anyway, why not set up a maintainable structure that
>> will continue to work beyond this publicity release. The benefit
>> to users is that aries will be able to release bits in a timely
>> fashion; otherwise the entire project will never be in a releasable
>> state at once. (I'm only exaggerating a little bit :-)
>> What got me looking at this at all is what look like wild gyrations
>> that don't really use maven properly to get an .eba (or some
>> artifact) out the door. This might be ok for one release but (a) I
>> think this can be done directly with the assembly plugin short term
>> and (b) an eba-maven-plugin seems like the obvious more long term
>> solution.
>> I'm willing to fix the build and probably work on an eba plugin,
>> but want to be sure this is ok with everyone first.
>
>
> The svn info can be added to support the maven-release-plugin
> without reorganizing to support independent component releases. But
> I agree that it would be nice to have the option of independent
> releases even if we intend to release all components in this first
> release. So in general, I'm in favor of the reorganization.
>
> As I mentioned earlier, I am concerned about the eba generation as
> well. I think a maven-eba-plugin would be preferred versus the
> alternative I mentioned of releasing the ebas simply as jars (again,
> assuming that the application code can deal with an archive of type
> jar instead of eba). I am using the maven-assembly-plugin to
> generate the jar for the eba in the AriesTrader sample but I didn't
> find the magic formula necessary to create the archive with a type
> of eba rather than jar and so I resorted to using ant (which I know
> is bad). A maven-eba-plugin or the necessary configuration to get
> the maven-release-plugin to generate something of type eba would
> sure be nice.
>
> I guess the key question might be how long it would take to make
> these changes and is it worth the wait.
I think I could reorganize the build wednesday and know if the eba
plugin would take more than a day to get sort of working in a day or
so. Of course I've been known to be overly optimistic in the past....
thanks
david jencks
>
> Joe
>
>> thanks
>> david jencks
>>>
>>> Thanks
>>> Alasdair
>>>
>>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com>
>>> wrote:
>>>
>>>> This discussion got me worried enough to take a look at the aries
>>>> build. Now I'm even more worried.
>>>>
>>>> While it might feel good to try to push out a release as fast as
>>>> possible I'd prefer to see a sustainable build system in place
>>>> first. So far it looks to me as if aries is going to be a bunch
>>>> of loosely coupled subprojects. Building them all at once is not
>>>> going to work for long. I think we should recognize that and put
>>>> that in the build system now. To me this means:
>>>>
>>>> 1. a parent pom that isn't at the root of the svn trunk.
>>>> 2. each subproject has pom info sufficient so it can be released
>>>> (mostly svn info) (right now this is completely missing
>>>> everywhere as far as I can see, which will result in ares getting
>>>> tagged into svn as part of the apache pom)
>>>>
>>>> We can still have a "fake" pom that builds everything, but it
>>>> won't be part of any release procedure.
>>>>
>>>> Having separately released subprojects does not prevent having a
>>>> single vote on all the releases.
>>>>
>>>> I'd suggest a few other pom tweaks such as using resources and
>>>> filtered-resources to distinguish when filtering is called for.
>>>>
>>>> In addition relevant to this particular bit of the thread, we
>>>> need an eba-maven-plugin to assemble ebas. Getting this into a
>>>> first release would be a great idea IMO.
>>>>
>>>> If there's general agreement I can spend some time playing with
>>>> the build and possibly working on the eba plugin.
>>>>
>>>> thoughts?
>>>>
>>>> thanks
>>>> david jencks
>>>>
>>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>>
>>>>> Jeremy Hughes wrote:
>>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>> I'd also like to see us release the sample applications but I
>>>>>>> think there is
>>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>>> generate EBAs
>>>>>>> using different techniques - but both leverage the maven-
>>>>>>> antrun-plugin to
>>>>>>> finally produce a file of type "eba".
>>>>>> I realised the .eba file generated in the blog-assembly module
>>>>>> wasn't
>>>>>> being pushed into my local repo. I've made some changes to the
>>>>>> pom.xml
>>>>>> in ARIES-198 to fix this. So now it uses antrun to create
>>>>>> the .eba
>>>>>> artifact and the build-helper-maven-plugin to push the artifact
>>>>>> to the
>>>>>> local repo. I needed to add NOTICE and LICENSE files to
>>>>>> the .eba for
>>>>>> the ianal plugin in the verify phase to succeed.
>>>>>
>>>>> I've not used the build-helper-maven-plugin before. Do you know
>>>>> if it will work with the maven-release-plugin to push the eba
>>>>> artifacts when we do a release? If so, then I should look at
>>>>> using the same mechanism for AriesTrader.
>>>>>
>>>>>>> I think the result is that the eba will not be available in a
>>>>>>> maven
>>>>>>> repository.
>>>>>>>
>>>>>>> One of the differences is that AriesTrader first generates a
>>>>>>> jar using the
>>>>>>> maven-assembly-plugin and then copies this to an eba. The jar
>>>>>>> will be
>>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>>> "application" even
>>>>>>> with an extension of "jar" rather than "eba". If that is
>>>>>>> correct then
>>>>>>> perhaps delivery of an application jar is an acceptable
>>>>>>> approach for the 1st
>>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>>> assembly to
>>>>>>> deploy the eba yet - it still deploys all of the individual
>>>>>>> bundles.
>>>>>> Using the maven-assembly-plugin likely the preferred approach
>>>>>> long
>>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>>> control and add the .eba one?
>>>>>
>>>>> I can give this a try for AriesTrader. If it doesn't work out -
>>>>> is there anything wrong with the approach I mentioned earlier of
>>>>> just using the jar artifacts rather than the eba artifacts?
>>>>> Will the current application support only look at *.eba archives?
>>>>>
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Guillaume Nodet wrote:
>>>>>>>> I'd like to see at least those included:
>>>>>>>> * blueprint
>>>>>>>> * jmx
>>>>>>>> * jndi
>>>>>>>> * transaction
>>>>>>>>
>>>>>>>> I don't think applications are really usable yet and I
>>>>>>>> haven't really
>>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>>> The transaction component is functional and we've been using
>>>>>>>> it mostly
>>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>>> Do you have any particular concerns with it ? (I'm not
>>>>>>>> talking about
>>>>>>>> declarative transactions for blueprint, note).
>>>>>>>>
>>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>>> volunteering
>>>>>>>>> to be the release manager. Your response helps me get a
>>>>>>>>> better picture
>>>>>>>>> of
>>>>>>>>> the plans.
>>>>>>>>>
>>>>>>>>> I was really just interested in the general objectives and
>>>>>>>>> timing since
>>>>>>>>> it
>>>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>>>> means it will
>>>>>>>>> be
>>>>>>>>> delivered next week. I'm afraid the hill might be a little
>>>>>>>>> too steep to
>>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>>
>>>>>>>>> The more communication the better. It's important to get
>>>>>>>>> everybody
>>>>>>>>> thinking
>>>>>>>>> and planning along the same lines (or understand quickly if
>>>>>>>>> there are any
>>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>>> creating a
>>>>>>>>> release candidate next week means that we should be getting
>>>>>>>>> more
>>>>>>>>> restrictive
>>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>>
>>>>>>>>> I don't have any strong opinions on what should be in or out
>>>>>>>>> - but in
>>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>>> functional.
>>>>>>>>> At
>>>>>>>>> the moment I'm not sure what those are - but I suspect not
>>>>>>>>> all of the
>>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>>
>>>>>>>>> Best Regards,
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am
>>>>>>>>>> now out on
>>>>>>>>>> vacation until monday.
>>>>>>>>>>
>>>>>>>>>> Personally, I think the 0.1 release should serve to get
>>>>>>>>>> what we have
>>>>>>>>>> right now in the respectable form the ASF requires. So
>>>>>>>>>> 'must haves'
>>>>>>>>>> are to get the build in the right shape to create the
>>>>>>>>>> distribution
>>>>>>>>>> files that are acceptable to the IPMC. I think each main
>>>>>>>>>> area of the
>>>>>>>>>> code deserves at least a README to describe what's
>>>>>>>>>> possible. Since
>>>>>>>>>> this is the first release there are likely a few unknowns -
>>>>>>>>>> w.r.t
>>>>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>>>>> there are
>>>>>>>>>> particular JIRAs or other issues you feel should be
>>>>>>>>>> included please
>>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1
>>>>>>>>>> and target
>>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to
>>>>>>>>>> target a new
>>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Jeremy
>>>>>>>>>>
>>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> Jeremy,
>>>>>>>>>>>
>>>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>>>> release and
>>>>>>>>>>> potential
>>>>>>>>>>> target dates?
>>>>>>>>>>>
>>>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>>>> thoughts in an
>>>>>>>>>>> email
>>>>>>>>>>> or
>>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as
>>>>>>>>>>> we make
>>>>>>>>>>> progress.
>>>>>>>>>>> Of particular interest would be the content that we would
>>>>>>>>>>> like to see
>>>>>>>>>>> in
>>>>>>>>>>> the first release (clarifying what we consider "must have"
>>>>>>>>>>> from "nice
>>>>>>>>>>> to
>>>>>>>>>>> have"), the current status of that content, target dates
>>>>>>>>>>> for the
>>>>>>>>>>> release,
>>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gnodet@gmail.com
>>>>>>>>>>>> > wrote:
>>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>>> I guess if you take some notes, it would be interesting
>>>>>>>>>>>>> to put those
>>>>>>>>>>>>> on the wiki.
>>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>>> process has
>>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hughesj@apache.org
>>>>>>>>>>>>> >
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <kevan.miller@gmail.com
>>>>>>>>>>>>>> >
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>>> components at a
>>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>>> scheme, IMO.
>>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Showing the ability to generate an Apache release is
>>>>>>>>>>>>>>> an important
>>>>>>>>>>>>>>> step
>>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Joe
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Joe
>>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Joe
>>>>
>
>
> --
> Joe
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
David Jencks wrote:
>
> On Feb 23, 2010, at 5:13 PM, Alasdair Nottingham wrote:
>
>> I'm am new to maven, so sorry if I show my ignorance.
>>
>> While I think I can see the value to what you suggest moving forward
>> if we choose to release sub-projects independantly (I say if because
>> we haven't discussed or agreed what tbd long term answer is yet) I do
>> not understand the benefit to a user of Aries of this change.
>>
>> As a result it does not appear to me to be key to resolve prior to
>> release.
>>
>> I would like to understand the problems you see better, but I do not
>> have the maven background you guys have, any chance you could explain
>> what the problems are, why they are problems and the solution at some
>> point?
>
> The biggest immediate problem is that without correct svn info you can't
> do a release with the release plugin. I'm pretty sure the way its set
> up now, when you try, the tag will be under maven's apache pom, not
> aries. (you'll fail unless you happen to be a maven committer too). You
> definitely don't want to try to do a release without the release plugin.
>
> Organizationally there's no way that for instance blueprint,
> application, and samples should always be released in synchrony. Any
> time two of them happen to be ready for release at the same time it will
> be purely accidental. Right now everyone wants to get a milestone out
> the door, but looking at the different projects their state of
> completion is pretty much wildly different. A decision to release all
> of them at once is not based in any way on them being equally complete.
> I'm suggesting that since build fixes are needed anyway, why not set up
> a maintainable structure that will continue to work beyond this
> publicity release. The benefit to users is that aries will be able to
> release bits in a timely fashion; otherwise the entire project will
> never be in a releasable state at once. (I'm only exaggerating a little
> bit :-)
>
> What got me looking at this at all is what look like wild gyrations that
> don't really use maven properly to get an .eba (or some artifact) out
> the door. This might be ok for one release but (a) I think this can be
> done directly with the assembly plugin short term and (b) an
> eba-maven-plugin seems like the obvious more long term solution.
>
> I'm willing to fix the build and probably work on an eba plugin, but
> want to be sure this is ok with everyone first.
The svn info can be added to support the maven-release-plugin without
reorganizing to support independent component releases. But I agree
that it would be nice to have the option of independent releases even if
we intend to release all components in this first release. So in
general, I'm in favor of the reorganization.
As I mentioned earlier, I am concerned about the eba generation as well.
I think a maven-eba-plugin would be preferred versus the alternative I
mentioned of releasing the ebas simply as jars (again, assuming that the
application code can deal with an archive of type jar instead of eba).
I am using the maven-assembly-plugin to generate the jar for the eba in
the AriesTrader sample but I didn't find the magic formula necessary to
create the archive with a type of eba rather than jar and so I resorted
to using ant (which I know is bad). A maven-eba-plugin or the
necessary configuration to get the maven-release-plugin to generate
something of type eba would sure be nice.
I guess the key question might be how long it would take to make these
changes and is it worth the wait.
Joe
>
> thanks
> david jencks
>
>>
>> Thanks
>> Alasdair
>>
>> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com> wrote:
>>
>>> This discussion got me worried enough to take a look at the aries
>>> build. Now I'm even more worried.
>>>
>>> While it might feel good to try to push out a release as fast as
>>> possible I'd prefer to see a sustainable build system in place
>>> first. So far it looks to me as if aries is going to be a bunch of
>>> loosely coupled subprojects. Building them all at once is not going
>>> to work for long. I think we should recognize that and put that in
>>> the build system now. To me this means:
>>>
>>> 1. a parent pom that isn't at the root of the svn trunk.
>>> 2. each subproject has pom info sufficient so it can be released
>>> (mostly svn info) (right now this is completely missing everywhere
>>> as far as I can see, which will result in ares getting tagged into
>>> svn as part of the apache pom)
>>>
>>> We can still have a "fake" pom that builds everything, but it won't
>>> be part of any release procedure.
>>>
>>> Having separately released subprojects does not prevent having a
>>> single vote on all the releases.
>>>
>>> I'd suggest a few other pom tweaks such as using resources and
>>> filtered-resources to distinguish when filtering is called for.
>>>
>>> In addition relevant to this particular bit of the thread, we need an
>>> eba-maven-plugin to assemble ebas. Getting this into a first release
>>> would be a great idea IMO.
>>>
>>> If there's general agreement I can spend some time playing with the
>>> build and possibly working on the eba plugin.
>>>
>>> thoughts?
>>>
>>> thanks
>>> david jencks
>>>
>>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>>
>>>> Jeremy Hughes wrote:
>>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>>> I'd also like to see us release the sample applications but I
>>>>>> think there is
>>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>>> generate EBAs
>>>>>> using different techniques - but both leverage the
>>>>>> maven-antrun-plugin to
>>>>>> finally produce a file of type "eba".
>>>>> I realised the .eba file generated in the blog-assembly module wasn't
>>>>> being pushed into my local repo. I've made some changes to the pom.xml
>>>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>>>>> artifact and the build-helper-maven-plugin to push the artifact to the
>>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba for
>>>>> the ianal plugin in the verify phase to succeed.
>>>>
>>>> I've not used the build-helper-maven-plugin before. Do you know if
>>>> it will work with the maven-release-plugin to push the eba artifacts
>>>> when we do a release? If so, then I should look at using the same
>>>> mechanism for AriesTrader.
>>>>
>>>>>> I think the result is that the eba will not be available in a maven
>>>>>> repository.
>>>>>>
>>>>>> One of the differences is that AriesTrader first generates a jar
>>>>>> using the
>>>>>> maven-assembly-plugin and then copies this to an eba. The jar
>>>>>> will be
>>>>>> managed by maven and IIUC it should be deployable as an
>>>>>> "application" even
>>>>>> with an extension of "jar" rather than "eba". If that is correct
>>>>>> then
>>>>>> perhaps delivery of an application jar is an acceptable approach
>>>>>> for the 1st
>>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>>> assembly to
>>>>>> deploy the eba yet - it still deploys all of the individual bundles.
>>>>> Using the maven-assembly-plugin likely the preferred approach long
>>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>>> control and add the .eba one?
>>>>
>>>> I can give this a try for AriesTrader. If it doesn't work out - is
>>>> there anything wrong with the approach I mentioned earlier of just
>>>> using the jar artifacts rather than the eba artifacts? Will the
>>>> current application support only look at *.eba archives?
>>>>
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>> Guillaume Nodet wrote:
>>>>>>> I'd like to see at least those included:
>>>>>>> * blueprint
>>>>>>> * jmx
>>>>>>> * jndi
>>>>>>> * transaction
>>>>>>>
>>>>>>> I don't think applications are really usable yet and I haven't
>>>>>>> really
>>>>>>> looked at JPA yet, so can't tell about it.
>>>>>>> The transaction component is functional and we've been using it
>>>>>>> mostly
>>>>>>> unchanged since a long time in ServiceMix.
>>>>>>> Do you have any particular concerns with it ? (I'm not talking about
>>>>>>> declarative transactions for blueprint, note).
>>>>>>>
>>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>>> volunteering
>>>>>>>> to be the release manager. Your response helps me get a better
>>>>>>>> picture
>>>>>>>> of
>>>>>>>> the plans.
>>>>>>>>
>>>>>>>> I was really just interested in the general objectives and
>>>>>>>> timing since
>>>>>>>> it
>>>>>>>> hadn't been discussed yet. To get the release out in Feb means
>>>>>>>> it will
>>>>>>>> be
>>>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>>>> steep to
>>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>>
>>>>>>>> The more communication the better. It's important to get everybody
>>>>>>>> thinking
>>>>>>>> and planning along the same lines (or understand quickly if
>>>>>>>> there are any
>>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>>> creating a
>>>>>>>> release candidate next week means that we should be getting more
>>>>>>>> restrictive
>>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>>
>>>>>>>> I don't have any strong opinions on what should be in or out -
>>>>>>>> but in
>>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>>> functional.
>>>>>>>> At
>>>>>>>> the moment I'm not sure what those are - but I suspect not all
>>>>>>>> of the
>>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>>
>>>>>>>> Best Regards,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now
>>>>>>>>> out on
>>>>>>>>> vacation until monday.
>>>>>>>>>
>>>>>>>>> Personally, I think the 0.1 release should serve to get what we
>>>>>>>>> have
>>>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>>>> haves'
>>>>>>>>> are to get the build in the right shape to create the distribution
>>>>>>>>> files that are acceptable to the IPMC. I think each main area
>>>>>>>>> of the
>>>>>>>>> code deserves at least a README to describe what's possible. Since
>>>>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>>>> there are
>>>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>>>> please
>>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>>>>> target
>>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a
>>>>>>>>> new
>>>>>>>>> 0.2 version. WDYT?
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Jeremy
>>>>>>>>>
>>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>>> Jeremy,
>>>>>>>>>>
>>>>>>>>>> What are your current thoughts and goals regarding the release
>>>>>>>>>> and
>>>>>>>>>> potential
>>>>>>>>>> target dates?
>>>>>>>>>>
>>>>>>>>>> I think it would be good if you could summarize your thoughts
>>>>>>>>>> in an
>>>>>>>>>> email
>>>>>>>>>> or
>>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>>>>>> progress.
>>>>>>>>>> Of particular interest would be the content that we would like
>>>>>>>>>> to see
>>>>>>>>>> in
>>>>>>>>>> the first release (clarifying what we consider "must have"
>>>>>>>>>> from "nice
>>>>>>>>>> to
>>>>>>>>>> have"), the current status of that content, target dates for the
>>>>>>>>>> release,
>>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>>> I guess if you take some notes, it would be interesting to
>>>>>>>>>>>> put those
>>>>>>>>>>>> on the wiki.
>>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>>> process has
>>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes
>>>>>>>>>>>> <hu...@apache.org>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller
>>>>>>>>>>>>> <ke...@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>>> components at a
>>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>>> scheme, IMO.
>>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>>> important
>>>>>>>>>>>>>> step
>>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>>> ------------------------
>>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>>> ------------------------
>>>>>>>>>>>> Open Source SOA
>>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Joe
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>>
>>>>
>>>> --
>>>> Joe
>>>
>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
On Feb 23, 2010, at 5:13 PM, Alasdair Nottingham wrote:
> I'm am new to maven, so sorry if I show my ignorance.
>
> While I think I can see the value to what you suggest moving forward
> if we choose to release sub-projects independantly (I say if because
> we haven't discussed or agreed what tbd long term answer is yet) I
> do not understand the benefit to a user of Aries of this change.
>
> As a result it does not appear to me to be key to resolve prior to
> release.
>
> I would like to understand the problems you see better, but I do not
> have the maven background you guys have, any chance you could
> explain what the problems are, why they are problems and the
> solution at some point?
The biggest immediate problem is that without correct svn info you
can't do a release with the release plugin. I'm pretty sure the way
its set up now, when you try, the tag will be under maven's apache
pom, not aries. (you'll fail unless you happen to be a maven
committer too). You definitely don't want to try to do a release
without the release plugin.
Organizationally there's no way that for instance blueprint,
application, and samples should always be released in synchrony. Any
time two of them happen to be ready for release at the same time it
will be purely accidental. Right now everyone wants to get a
milestone out the door, but looking at the different projects their
state of completion is pretty much wildly different. A decision to
release all of them at once is not based in any way on them being
equally complete. I'm suggesting that since build fixes are needed
anyway, why not set up a maintainable structure that will continue to
work beyond this publicity release. The benefit to users is that
aries will be able to release bits in a timely fashion; otherwise the
entire project will never be in a releasable state at once. (I'm only
exaggerating a little bit :-)
What got me looking at this at all is what look like wild gyrations
that don't really use maven properly to get an .eba (or some artifact)
out the door. This might be ok for one release but (a) I think this
can be done directly with the assembly plugin short term and (b) an
eba-maven-plugin seems like the obvious more long term solution.
I'm willing to fix the build and probably work on an eba plugin, but
want to be sure this is ok with everyone first.
thanks
david jencks
>
> Thanks
> Alasdair
>
> On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com> wrote:
>
>> This discussion got me worried enough to take a look at the aries
>> build. Now I'm even more worried.
>>
>> While it might feel good to try to push out a release as fast as
>> possible I'd prefer to see a sustainable build system in place
>> first. So far it looks to me as if aries is going to be a bunch of
>> loosely coupled subprojects. Building them all at once is not
>> going to work for long. I think we should recognize that and put
>> that in the build system now. To me this means:
>>
>> 1. a parent pom that isn't at the root of the svn trunk.
>> 2. each subproject has pom info sufficient so it can be released
>> (mostly svn info) (right now this is completely missing everywhere
>> as far as I can see, which will result in ares getting tagged into
>> svn as part of the apache pom)
>>
>> We can still have a "fake" pom that builds everything, but it won't
>> be part of any release procedure.
>>
>> Having separately released subprojects does not prevent having a
>> single vote on all the releases.
>>
>> I'd suggest a few other pom tweaks such as using resources and
>> filtered-resources to distinguish when filtering is called for.
>>
>> In addition relevant to this particular bit of the thread, we need
>> an eba-maven-plugin to assemble ebas. Getting this into a first
>> release would be a great idea IMO.
>>
>> If there's general agreement I can spend some time playing with the
>> build and possibly working on the eba plugin.
>>
>> thoughts?
>>
>> thanks
>> david jencks
>>
>> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>>
>>> Jeremy Hughes wrote:
>>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>>> I'd also like to see us release the sample applications but I
>>>>> think there is
>>>>> at least one complication. Both Blog Sample and AriesTrader
>>>>> generate EBAs
>>>>> using different techniques - but both leverage the maven-antrun-
>>>>> plugin to
>>>>> finally produce a file of type "eba".
>>>> I realised the .eba file generated in the blog-assembly module
>>>> wasn't
>>>> being pushed into my local repo. I've made some changes to the
>>>> pom.xml
>>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>>>> artifact and the build-helper-maven-plugin to push the artifact
>>>> to the
>>>> local repo. I needed to add NOTICE and LICENSE files to the .eba
>>>> for
>>>> the ianal plugin in the verify phase to succeed.
>>>
>>> I've not used the build-helper-maven-plugin before. Do you know
>>> if it will work with the maven-release-plugin to push the eba
>>> artifacts when we do a release? If so, then I should look at
>>> using the same mechanism for AriesTrader.
>>>
>>>>> I think the result is that the eba will not be available in a
>>>>> maven
>>>>> repository.
>>>>>
>>>>> One of the differences is that AriesTrader first generates a jar
>>>>> using the
>>>>> maven-assembly-plugin and then copies this to an eba. The jar
>>>>> will be
>>>>> managed by maven and IIUC it should be deployable as an
>>>>> "application" even
>>>>> with an extension of "jar" rather than "eba". If that is
>>>>> correct then
>>>>> perhaps delivery of an application jar is an acceptable approach
>>>>> for the 1st
>>>>> release. Unfortunately I haven't actually setup my equinox
>>>>> assembly to
>>>>> deploy the eba yet - it still deploys all of the individual
>>>>> bundles.
>>>> Using the maven-assembly-plugin likely the preferred approach long
>>>> term. Perhaps we could copy the artifact to .eba and use the
>>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>>> control and add the .eba one?
>>>
>>> I can give this a try for AriesTrader. If it doesn't work out -
>>> is there anything wrong with the approach I mentioned earlier of
>>> just using the jar artifacts rather than the eba artifacts? Will
>>> the current application support only look at *.eba archives?
>>>
>>>>> Joe
>>>>>
>>>>>
>>>>>
>>>>> Guillaume Nodet wrote:
>>>>>> I'd like to see at least those included:
>>>>>> * blueprint
>>>>>> * jmx
>>>>>> * jndi
>>>>>> * transaction
>>>>>>
>>>>>> I don't think applications are really usable yet and I haven't
>>>>>> really
>>>>>> looked at JPA yet, so can't tell about it.
>>>>>> The transaction component is functional and we've been using it
>>>>>> mostly
>>>>>> unchanged since a long time in ServiceMix.
>>>>>> Do you have any particular concerns with it ? (I'm not talking
>>>>>> about
>>>>>> declarative transactions for blueprint, note).
>>>>>>
>>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com>
>>>>>> wrote:
>>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>>> volunteering
>>>>>>> to be the release manager. Your response helps me get a
>>>>>>> better picture
>>>>>>> of
>>>>>>> the plans.
>>>>>>>
>>>>>>> I was really just interested in the general objectives and
>>>>>>> timing since
>>>>>>> it
>>>>>>> hadn't been discussed yet. To get the release out in Feb
>>>>>>> means it will
>>>>>>> be
>>>>>>> delivered next week. I'm afraid the hill might be a little
>>>>>>> too steep to
>>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>>
>>>>>>> The more communication the better. It's important to get
>>>>>>> everybody
>>>>>>> thinking
>>>>>>> and planning along the same lines (or understand quickly if
>>>>>>> there are any
>>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>>> creating a
>>>>>>> release candidate next week means that we should be getting more
>>>>>>> restrictive
>>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>>
>>>>>>> I don't have any strong opinions on what should be in or out -
>>>>>>> but in
>>>>>>> general it doesn't make sense to release things that aren't
>>>>>>> functional.
>>>>>>> At
>>>>>>> the moment I'm not sure what those are - but I suspect not all
>>>>>>> of the
>>>>>>> components are fully functional yet (for example transaction).
>>>>>>>
>>>>>>> Best Regards,
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>> Jeremy Hughes wrote:
>>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now
>>>>>>>> out on
>>>>>>>> vacation until monday.
>>>>>>>>
>>>>>>>> Personally, I think the 0.1 release should serve to get what
>>>>>>>> we have
>>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>>> haves'
>>>>>>>> are to get the build in the right shape to create the
>>>>>>>> distribution
>>>>>>>> files that are acceptable to the IPMC. I think each main area
>>>>>>>> of the
>>>>>>>> code deserves at least a README to describe what's possible.
>>>>>>>> Since
>>>>>>>> this is the first release there are likely a few unknowns -
>>>>>>>> w.r.t
>>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>>> there are
>>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>>> please
>>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1
>>>>>>>> and target
>>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target
>>>>>>>> a new
>>>>>>>> 0.2 version. WDYT?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Jeremy
>>>>>>>>
>>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>>> Jeremy,
>>>>>>>>>
>>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>>> release and
>>>>>>>>> potential
>>>>>>>>> target dates?
>>>>>>>>>
>>>>>>>>> I think it would be good if you could summarize your
>>>>>>>>> thoughts in an
>>>>>>>>> email
>>>>>>>>> or
>>>>>>>>> perhaps on a page in the wiki that we can keep updated as we
>>>>>>>>> make
>>>>>>>>> progress.
>>>>>>>>> Of particular interest would be the content that we would
>>>>>>>>> like to see
>>>>>>>>> in
>>>>>>>>> the first release (clarifying what we consider "must have"
>>>>>>>>> from "nice
>>>>>>>>> to
>>>>>>>>> have"), the current status of that content, target dates for
>>>>>>>>> the
>>>>>>>>> release,
>>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>>> <gn...@gmail.com> wrote:
>>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>>> I guess if you take some notes, it would be interesting to
>>>>>>>>>>> put those
>>>>>>>>>>> on the wiki.
>>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>>> process has
>>>>>>>>>> changed quite a bit :-)
>>>>>>>>>>
>>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hughesj@apache.org
>>>>>>>>>>> >
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>>
>>>>>>>>>>>> Jeremy
>>>>>>>>>>>>
>>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <kevan.miller@gmail.com
>>>>>>>>>>>> >
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>>> components at a
>>>>>>>>>>>>> 0.1
>>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>>> scheme, IMO.
>>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>>> issue.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>>> important
>>>>>>>>>>>>> step
>>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>>> happen...
>>>>>>>>>>>>>
>>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>>
>>>>>>>>>>>>> --kevan
>>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Guillaume Nodet
>>>>>>>>>>> ------------------------
>>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>>> ------------------------
>>>>>>>>>>> Open Source SOA
>>>>>>>>>>> http://fusesource.com
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>> --
>>>>>>> Joe
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>
>>>
>>> --
>>> Joe
>>
Re: [DISCUSSION] Aries release
Posted by Alasdair Nottingham <no...@apache.org>.
I'm am new to maven, so sorry if I show my ignorance.
While I think I can see the value to what you suggest moving forward
if we choose to release sub-projects independantly (I say if because
we haven't discussed or agreed what tbd long term answer is yet) I do
not understand the benefit to a user of Aries of this change.
As a result it does not appear to me to be key to resolve prior to
release.
I would like to understand the problems you see better, but I do not
have the maven background you guys have, any chance you could explain
what the problems are, why they are problems and the solution at some
point?
Thanks
Alasdair
On 23 Feb 2010, at 18:18, David Jencks <da...@yahoo.com> wrote:
> This discussion got me worried enough to take a look at the aries
> build. Now I'm even more worried.
>
> While it might feel good to try to push out a release as fast as
> possible I'd prefer to see a sustainable build system in place
> first. So far it looks to me as if aries is going to be a bunch of
> loosely coupled subprojects. Building them all at once is not going
> to work for long. I think we should recognize that and put that in
> the build system now. To me this means:
>
> 1. a parent pom that isn't at the root of the svn trunk.
> 2. each subproject has pom info sufficient so it can be released
> (mostly svn info) (right now this is completely missing everywhere
> as far as I can see, which will result in ares getting tagged into
> svn as part of the apache pom)
>
> We can still have a "fake" pom that builds everything, but it won't
> be part of any release procedure.
>
> Having separately released subprojects does not prevent having a
> single vote on all the releases.
>
> I'd suggest a few other pom tweaks such as using resources and
> filtered-resources to distinguish when filtering is called for.
>
> In addition relevant to this particular bit of the thread, we need
> an eba-maven-plugin to assemble ebas. Getting this into a first
> release would be a great idea IMO.
>
> If there's general agreement I can spend some time playing with the
> build and possibly working on the eba plugin.
>
> thoughts?
>
> thanks
> david jencks
>
> On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
>
>> Jeremy Hughes wrote:
>>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>>> I'd also like to see us release the sample applications but I
>>>> think there is
>>>> at least one complication. Both Blog Sample and AriesTrader
>>>> generate EBAs
>>>> using different techniques - but both leverage the maven-antrun-
>>>> plugin to
>>>> finally produce a file of type "eba".
>>> I realised the .eba file generated in the blog-assembly module
>>> wasn't
>>> being pushed into my local repo. I've made some changes to the
>>> pom.xml
>>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>>> artifact and the build-helper-maven-plugin to push the artifact to
>>> the
>>> local repo. I needed to add NOTICE and LICENSE files to the .eba for
>>> the ianal plugin in the verify phase to succeed.
>>
>> I've not used the build-helper-maven-plugin before. Do you know if
>> it will work with the maven-release-plugin to push the eba
>> artifacts when we do a release? If so, then I should look at using
>> the same mechanism for AriesTrader.
>>
>>>> I think the result is that the eba will not be available in a maven
>>>> repository.
>>>>
>>>> One of the differences is that AriesTrader first generates a jar
>>>> using the
>>>> maven-assembly-plugin and then copies this to an eba. The jar
>>>> will be
>>>> managed by maven and IIUC it should be deployable as an
>>>> "application" even
>>>> with an extension of "jar" rather than "eba". If that is correct
>>>> then
>>>> perhaps delivery of an application jar is an acceptable approach
>>>> for the 1st
>>>> release. Unfortunately I haven't actually setup my equinox
>>>> assembly to
>>>> deploy the eba yet - it still deploys all of the individual
>>>> bundles.
>>> Using the maven-assembly-plugin likely the preferred approach long
>>> term. Perhaps we could copy the artifact to .eba and use the
>>> build-helper-maven-plugin to remove the .jar artifact from maven
>>> control and add the .eba one?
>>
>> I can give this a try for AriesTrader. If it doesn't work out - is
>> there anything wrong with the approach I mentioned earlier of just
>> using the jar artifacts rather than the eba artifacts? Will the
>> current application support only look at *.eba archives?
>>
>>>> Joe
>>>>
>>>>
>>>>
>>>> Guillaume Nodet wrote:
>>>>> I'd like to see at least those included:
>>>>> * blueprint
>>>>> * jmx
>>>>> * jndi
>>>>> * transaction
>>>>>
>>>>> I don't think applications are really usable yet and I haven't
>>>>> really
>>>>> looked at JPA yet, so can't tell about it.
>>>>> The transaction component is functional and we've been using it
>>>>> mostly
>>>>> unchanged since a long time in ServiceMix.
>>>>> Do you have any particular concerns with it ? (I'm not talking
>>>>> about
>>>>> declarative transactions for blueprint, note).
>>>>>
>>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>>> volunteering
>>>>>> to be the release manager. Your response helps me get a better
>>>>>> picture
>>>>>> of
>>>>>> the plans.
>>>>>>
>>>>>> I was really just interested in the general objectives and
>>>>>> timing since
>>>>>> it
>>>>>> hadn't been discussed yet. To get the release out in Feb means
>>>>>> it will
>>>>>> be
>>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>>> steep to
>>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>>
>>>>>> The more communication the better. It's important to get
>>>>>> everybody
>>>>>> thinking
>>>>>> and planning along the same lines (or understand quickly if
>>>>>> there are any
>>>>>> differences of opinion). Knowing that you are thinking of
>>>>>> creating a
>>>>>> release candidate next week means that we should be getting more
>>>>>> restrictive
>>>>>> on new content to avoid any unpleasant surprises.
>>>>>>
>>>>>> I don't have any strong opinions on what should be in or out -
>>>>>> but in
>>>>>> general it doesn't make sense to release things that aren't
>>>>>> functional.
>>>>>> At
>>>>>> the moment I'm not sure what those are - but I suspect not all
>>>>>> of the
>>>>>> components are fully functional yet (for example transaction).
>>>>>>
>>>>>> Best Regards,
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now
>>>>>>> out on
>>>>>>> vacation until monday.
>>>>>>>
>>>>>>> Personally, I think the 0.1 release should serve to get what
>>>>>>> we have
>>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>>> haves'
>>>>>>> are to get the build in the right shape to create the
>>>>>>> distribution
>>>>>>> files that are acceptable to the IPMC. I think each main area
>>>>>>> of the
>>>>>>> code deserves at least a README to describe what's possible.
>>>>>>> Since
>>>>>>> this is the first release there are likely a few unknowns -
>>>>>>> w.r.t
>>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>>> there are
>>>>>>> particular JIRAs or other issues you feel should be included
>>>>>>> please
>>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1
>>>>>>> and target
>>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target
>>>>>>> a new
>>>>>>> 0.2 version. WDYT?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Jeremy
>>>>>>>
>>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>>> Jeremy,
>>>>>>>>
>>>>>>>> What are your current thoughts and goals regarding the
>>>>>>>> release and
>>>>>>>> potential
>>>>>>>> target dates?
>>>>>>>>
>>>>>>>> I think it would be good if you could summarize your thoughts
>>>>>>>> in an
>>>>>>>> email
>>>>>>>> or
>>>>>>>> perhaps on a page in the wiki that we can keep updated as we
>>>>>>>> make
>>>>>>>> progress.
>>>>>>>> Of particular interest would be the content that we would
>>>>>>>> like to see
>>>>>>>> in
>>>>>>>> the first release (clarifying what we consider "must have"
>>>>>>>> from "nice
>>>>>>>> to
>>>>>>>> have"), the current status of that content, target dates for
>>>>>>>> the
>>>>>>>> release,
>>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Jeremy Hughes wrote:
>>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet
>>>>>>>>> <gn...@gmail.com> wrote:
>>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>>> I guess if you take some notes, it would be interesting to
>>>>>>>>>> put those
>>>>>>>>>> on the wiki.
>>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>>> process has
>>>>>>>>> changed quite a bit :-)
>>>>>>>>>
>>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hughesj@apache.org
>>>>>>>>>> >
>>>>>>>>>> wrote:
>>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>>
>>>>>>>>>>> Jeremy
>>>>>>>>>>>
>>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <kevan.miller@gmail.com
>>>>>>>>>>> >
>>>>>>>>>>> wrote:
>>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>>> components at a
>>>>>>>>>>>> 0.1
>>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>>> scheme, IMO.
>>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>>> issue.
>>>>>>>>>>>>
>>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>>> important
>>>>>>>>>>>> step
>>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>>> happen...
>>>>>>>>>>>>
>>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>>
>>>>>>>>>>>> --kevan
>>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Cheers,
>>>>>>>>>> Guillaume Nodet
>>>>>>>>>> ------------------------
>>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>>> ------------------------
>>>>>>>>>> Open Source SOA
>>>>>>>>>> http://fusesource.com
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Joe
>>>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Joe
>>>>
>>
>>
>> --
>> Joe
>
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
This discussion got me worried enough to take a look at the aries
build. Now I'm even more worried.
While it might feel good to try to push out a release as fast as
possible I'd prefer to see a sustainable build system in place first.
So far it looks to me as if aries is going to be a bunch of loosely
coupled subprojects. Building them all at once is not going to work
for long. I think we should recognize that and put that in the build
system now. To me this means:
1. a parent pom that isn't at the root of the svn trunk.
2. each subproject has pom info sufficient so it can be released
(mostly svn info) (right now this is completely missing everywhere as
far as I can see, which will result in ares getting tagged into svn as
part of the apache pom)
We can still have a "fake" pom that builds everything, but it won't be
part of any release procedure.
Having separately released subprojects does not prevent having a
single vote on all the releases.
I'd suggest a few other pom tweaks such as using resources and
filtered-resources to distinguish when filtering is called for.
In addition relevant to this particular bit of the thread, we need an
eba-maven-plugin to assemble ebas. Getting this into a first release
would be a great idea IMO.
If there's general agreement I can spend some time playing with the
build and possibly working on the eba plugin.
thoughts?
thanks
david jencks
On Feb 22, 2010, at 2:01 PM, Joe Bohn wrote:
> Jeremy Hughes wrote:
>> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>>> I'd also like to see us release the sample applications but I
>>> think there is
>>> at least one complication. Both Blog Sample and AriesTrader
>>> generate EBAs
>>> using different techniques - but both leverage the maven-antrun-
>>> plugin to
>>> finally produce a file of type "eba".
>> I realised the .eba file generated in the blog-assembly module wasn't
>> being pushed into my local repo. I've made some changes to the
>> pom.xml
>> in ARIES-198 to fix this. So now it uses antrun to create the .eba
>> artifact and the build-helper-maven-plugin to push the artifact to
>> the
>> local repo. I needed to add NOTICE and LICENSE files to the .eba for
>> the ianal plugin in the verify phase to succeed.
>
> I've not used the build-helper-maven-plugin before. Do you know if
> it will work with the maven-release-plugin to push the eba artifacts
> when we do a release? If so, then I should look at using the same
> mechanism for AriesTrader.
>
>>> I think the result is that the eba will not be available in a maven
>>> repository.
>>>
>>> One of the differences is that AriesTrader first generates a jar
>>> using the
>>> maven-assembly-plugin and then copies this to an eba. The jar
>>> will be
>>> managed by maven and IIUC it should be deployable as an
>>> "application" even
>>> with an extension of "jar" rather than "eba". If that is correct
>>> then
>>> perhaps delivery of an application jar is an acceptable approach
>>> for the 1st
>>> release. Unfortunately I haven't actually setup my equinox
>>> assembly to
>>> deploy the eba yet - it still deploys all of the individual bundles.
>> Using the maven-assembly-plugin likely the preferred approach long
>> term. Perhaps we could copy the artifact to .eba and use the
>> build-helper-maven-plugin to remove the .jar artifact from maven
>> control and add the .eba one?
>
> I can give this a try for AriesTrader. If it doesn't work out - is
> there anything wrong with the approach I mentioned earlier of just
> using the jar artifacts rather than the eba artifacts? Will the
> current application support only look at *.eba archives?
>
>>> Joe
>>>
>>>
>>>
>>> Guillaume Nodet wrote:
>>>> I'd like to see at least those included:
>>>> * blueprint
>>>> * jmx
>>>> * jndi
>>>> * transaction
>>>>
>>>> I don't think applications are really usable yet and I haven't
>>>> really
>>>> looked at JPA yet, so can't tell about it.
>>>> The transaction component is functional and we've been using it
>>>> mostly
>>>> unchanged since a long time in ServiceMix.
>>>> Do you have any particular concerns with it ? (I'm not talking
>>>> about
>>>> declarative transactions for blueprint, note).
>>>>
>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>> volunteering
>>>>> to be the release manager. Your response helps me get a better
>>>>> picture
>>>>> of
>>>>> the plans.
>>>>>
>>>>> I was really just interested in the general objectives and
>>>>> timing since
>>>>> it
>>>>> hadn't been discussed yet. To get the release out in Feb means
>>>>> it will
>>>>> be
>>>>> delivered next week. I'm afraid the hill might be a little too
>>>>> steep to
>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>
>>>>> The more communication the better. It's important to get
>>>>> everybody
>>>>> thinking
>>>>> and planning along the same lines (or understand quickly if
>>>>> there are any
>>>>> differences of opinion). Knowing that you are thinking of
>>>>> creating a
>>>>> release candidate next week means that we should be getting more
>>>>> restrictive
>>>>> on new content to avoid any unpleasant surprises.
>>>>>
>>>>> I don't have any strong opinions on what should be in or out -
>>>>> but in
>>>>> general it doesn't make sense to release things that aren't
>>>>> functional.
>>>>> At
>>>>> the moment I'm not sure what those are - but I suspect not all
>>>>> of the
>>>>> components are fully functional yet (for example transaction).
>>>>>
>>>>> Best Regards,
>>>>> Joe
>>>>>
>>>>>
>>>>> Jeremy Hughes wrote:
>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now
>>>>>> out on
>>>>>> vacation until monday.
>>>>>>
>>>>>> Personally, I think the 0.1 release should serve to get what we
>>>>>> have
>>>>>> right now in the respectable form the ASF requires. So 'must
>>>>>> haves'
>>>>>> are to get the build in the right shape to create the
>>>>>> distribution
>>>>>> files that are acceptable to the IPMC. I think each main area
>>>>>> of the
>>>>>> code deserves at least a README to describe what's possible.
>>>>>> Since
>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>> timing I hope/expect to get the release out this in feb. If
>>>>>> there are
>>>>>> particular JIRAs or other issues you feel should be included
>>>>>> please
>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and
>>>>>> target
>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a
>>>>>> new
>>>>>> 0.2 version. WDYT?
>>>>>>
>>>>>> Cheers,
>>>>>> Jeremy
>>>>>>
>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>> Jeremy,
>>>>>>>
>>>>>>> What are your current thoughts and goals regarding the release
>>>>>>> and
>>>>>>> potential
>>>>>>> target dates?
>>>>>>>
>>>>>>> I think it would be good if you could summarize your thoughts
>>>>>>> in an
>>>>>>> email
>>>>>>> or
>>>>>>> perhaps on a page in the wiki that we can keep updated as we
>>>>>>> make
>>>>>>> progress.
>>>>>>> Of particular interest would be the content that we would like
>>>>>>> to see
>>>>>>> in
>>>>>>> the first release (clarifying what we consider "must have"
>>>>>>> from "nice
>>>>>>> to
>>>>>>> have"), the current status of that content, target dates for the
>>>>>>> release,
>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jeremy Hughes wrote:
>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>> I guess if you take some notes, it would be interesting to
>>>>>>>>> put those
>>>>>>>>> on the wiki.
>>>>>>>> Certainly will. It's been a while since I did one and the
>>>>>>>> process has
>>>>>>>> changed quite a bit :-)
>>>>>>>>
>>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hughesj@apache.org
>>>>>>>>> >
>>>>>>>>> wrote:
>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>
>>>>>>>>>> Jeremy
>>>>>>>>>>
>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <kevan.miller@gmail.com
>>>>>>>>>> >
>>>>>>>>>> wrote:
>>>>>>>>>>> Sounds like the consensus is for a release with all
>>>>>>>>>>> components at a
>>>>>>>>>>> 0.1
>>>>>>>>>>> version number. Best to start with a simple versioning
>>>>>>>>>>> scheme, IMO.
>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an
>>>>>>>>>>> issue.
>>>>>>>>>>>
>>>>>>>>>>> Showing the ability to generate an Apache release is an
>>>>>>>>>>> important
>>>>>>>>>>> step
>>>>>>>>>>> for the community. Would definitely like to see this
>>>>>>>>>>> happen...
>>>>>>>>>>>
>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>
>>>>>>>>>>> --kevan
>>>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> Open Source SOA
>>>>>>>>> http://fusesource.com
>>>>>>>>>
>>>>>>> --
>>>>>>> Joe
>>>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Joe
>>>
>
>
> --
> Joe
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
Jeremy Hughes wrote:
> On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
>> I'd also like to see us release the sample applications but I think there is
>> at least one complication. Both Blog Sample and AriesTrader generate EBAs
>> using different techniques - but both leverage the maven-antrun-plugin to
>> finally produce a file of type "eba".
>
> I realised the .eba file generated in the blog-assembly module wasn't
> being pushed into my local repo. I've made some changes to the pom.xml
> in ARIES-198 to fix this. So now it uses antrun to create the .eba
> artifact and the build-helper-maven-plugin to push the artifact to the
> local repo. I needed to add NOTICE and LICENSE files to the .eba for
> the ianal plugin in the verify phase to succeed.
I've not used the build-helper-maven-plugin before. Do you know if it
will work with the maven-release-plugin to push the eba artifacts when
we do a release? If so, then I should look at using the same mechanism
for AriesTrader.
>
>> I think the result is that the eba will not be available in a maven
>> repository.
>>
>> One of the differences is that AriesTrader first generates a jar using the
>> maven-assembly-plugin and then copies this to an eba. The jar will be
>> managed by maven and IIUC it should be deployable as an "application" even
>> with an extension of "jar" rather than "eba". If that is correct then
>> perhaps delivery of an application jar is an acceptable approach for the 1st
>> release. Unfortunately I haven't actually setup my equinox assembly to
>> deploy the eba yet - it still deploys all of the individual bundles.
>
> Using the maven-assembly-plugin likely the preferred approach long
> term. Perhaps we could copy the artifact to .eba and use the
> build-helper-maven-plugin to remove the .jar artifact from maven
> control and add the .eba one?
I can give this a try for AriesTrader. If it doesn't work out - is
there anything wrong with the approach I mentioned earlier of just using
the jar artifacts rather than the eba artifacts? Will the current
application support only look at *.eba archives?
>> Joe
>>
>>
>>
>> Guillaume Nodet wrote:
>>> I'd like to see at least those included:
>>> * blueprint
>>> * jmx
>>> * jndi
>>> * transaction
>>>
>>> I don't think applications are really usable yet and I haven't really
>>> looked at JPA yet, so can't tell about it.
>>> The transaction component is functional and we've been using it mostly
>>> unchanged since a long time in ServiceMix.
>>> Do you have any particular concerns with it ? (I'm not talking about
>>> declarative transactions for blueprint, note).
>>>
>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>> Thanks for the response (even while on vacation!) ... and for
>>>> volunteering
>>>> to be the release manager. Your response helps me get a better picture
>>>> of
>>>> the plans.
>>>>
>>>> I was really just interested in the general objectives and timing since
>>>> it
>>>> hadn't been discussed yet. To get the release out in Feb means it will
>>>> be
>>>> delivered next week. I'm afraid the hill might be a little too steep to
>>>> climb that quickly but I'm happy to be proven wrong.
>>>>
>>>> The more communication the better. It's important to get everybody
>>>> thinking
>>>> and planning along the same lines (or understand quickly if there are any
>>>> differences of opinion). Knowing that you are thinking of creating a
>>>> release candidate next week means that we should be getting more
>>>> restrictive
>>>> on new content to avoid any unpleasant surprises.
>>>>
>>>> I don't have any strong opinions on what should be in or out - but in
>>>> general it doesn't make sense to release things that aren't functional.
>>>> At
>>>> the moment I'm not sure what those are - but I suspect not all of the
>>>> components are fully functional yet (for example transaction).
>>>>
>>>> Best Regards,
>>>> Joe
>>>>
>>>>
>>>> Jeremy Hughes wrote:
>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>> vacation until monday.
>>>>>
>>>>> Personally, I think the 0.1 release should serve to get what we have
>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>> are to get the build in the right shape to create the distribution
>>>>> files that are acceptable to the IPMC. I think each main area of the
>>>>> code deserves at least a README to describe what's possible. Since
>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>> timing I hope/expect to get the release out this in feb. If there are
>>>>> particular JIRAs or other issues you feel should be included please
>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>> 0.2 version. WDYT?
>>>>>
>>>>> Cheers,
>>>>> Jeremy
>>>>>
>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>> Jeremy,
>>>>>>
>>>>>> What are your current thoughts and goals regarding the release and
>>>>>> potential
>>>>>> target dates?
>>>>>>
>>>>>> I think it would be good if you could summarize your thoughts in an
>>>>>> email
>>>>>> or
>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>> progress.
>>>>>> Of particular interest would be the content that we would like to see
>>>>>> in
>>>>>> the first release (clarifying what we consider "must have" from "nice
>>>>>> to
>>>>>> have"), the current status of that content, target dates for the
>>>>>> release,
>>>>>> and the process that we plan to use to generate the release.
>>>>>>
>>>>>> Thanks,
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>>> on the wiki.
>>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>>> changed quite a bit :-)
>>>>>>>
>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>>> wrote:
>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>
>>>>>>>>> Jeremy
>>>>>>>>>
>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>>> 0.1
>>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>
>>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>>> step
>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>
>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>
>>>>>>>>>> --kevan
>>>>>>>>>>
>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>> --
>>>>>> Joe
>>>>>>
>>>> --
>>>> Joe
>>>>
>>>
>>>
>>
>> --
>> Joe
>>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 19 February 2010 13:09, Joe Bohn <jo...@gmail.com> wrote:
> I'd also like to see us release the sample applications but I think there is
> at least one complication. Both Blog Sample and AriesTrader generate EBAs
> using different techniques - but both leverage the maven-antrun-plugin to
> finally produce a file of type "eba".
I realised the .eba file generated in the blog-assembly module wasn't
being pushed into my local repo. I've made some changes to the pom.xml
in ARIES-198 to fix this. So now it uses antrun to create the .eba
artifact and the build-helper-maven-plugin to push the artifact to the
local repo. I needed to add NOTICE and LICENSE files to the .eba for
the ianal plugin in the verify phase to succeed.
>
> I think the result is that the eba will not be available in a maven
> repository.
>
> One of the differences is that AriesTrader first generates a jar using the
> maven-assembly-plugin and then copies this to an eba. The jar will be
> managed by maven and IIUC it should be deployable as an "application" even
> with an extension of "jar" rather than "eba". If that is correct then
> perhaps delivery of an application jar is an acceptable approach for the 1st
> release. Unfortunately I haven't actually setup my equinox assembly to
> deploy the eba yet - it still deploys all of the individual bundles.
Using the maven-assembly-plugin likely the preferred approach long
term. Perhaps we could copy the artifact to .eba and use the
build-helper-maven-plugin to remove the .jar artifact from maven
control and add the .eba one?
>
> Joe
>
>
>
> Guillaume Nodet wrote:
>>
>> I'd like to see at least those included:
>> * blueprint
>> * jmx
>> * jndi
>> * transaction
>>
>> I don't think applications are really usable yet and I haven't really
>> looked at JPA yet, so can't tell about it.
>> The transaction component is functional and we've been using it mostly
>> unchanged since a long time in ServiceMix.
>> Do you have any particular concerns with it ? (I'm not talking about
>> declarative transactions for blueprint, note).
>>
>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>
>>> Thanks for the response (even while on vacation!) ... and for
>>> volunteering
>>> to be the release manager. Your response helps me get a better picture
>>> of
>>> the plans.
>>>
>>> I was really just interested in the general objectives and timing since
>>> it
>>> hadn't been discussed yet. To get the release out in Feb means it will
>>> be
>>> delivered next week. I'm afraid the hill might be a little too steep to
>>> climb that quickly but I'm happy to be proven wrong.
>>>
>>> The more communication the better. It's important to get everybody
>>> thinking
>>> and planning along the same lines (or understand quickly if there are any
>>> differences of opinion). Knowing that you are thinking of creating a
>>> release candidate next week means that we should be getting more
>>> restrictive
>>> on new content to avoid any unpleasant surprises.
>>>
>>> I don't have any strong opinions on what should be in or out - but in
>>> general it doesn't make sense to release things that aren't functional.
>>> At
>>> the moment I'm not sure what those are - but I suspect not all of the
>>> components are fully functional yet (for example transaction).
>>>
>>> Best Regards,
>>> Joe
>>>
>>>
>>> Jeremy Hughes wrote:
>>>>
>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>> vacation until monday.
>>>>
>>>> Personally, I think the 0.1 release should serve to get what we have
>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>> are to get the build in the right shape to create the distribution
>>>> files that are acceptable to the IPMC. I think each main area of the
>>>> code deserves at least a README to describe what's possible. Since
>>>> this is the first release there are likely a few unknowns - w.r.t
>>>> timing I hope/expect to get the release out this in feb. If there are
>>>> particular JIRAs or other issues you feel should be included please
>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>> 0.2 version. WDYT?
>>>>
>>>> Cheers,
>>>> Jeremy
>>>>
>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>
>>>>> Jeremy,
>>>>>
>>>>> What are your current thoughts and goals regarding the release and
>>>>> potential
>>>>> target dates?
>>>>>
>>>>> I think it would be good if you could summarize your thoughts in an
>>>>> email
>>>>> or
>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>> progress.
>>>>> Of particular interest would be the content that we would like to see
>>>>> in
>>>>> the first release (clarifying what we consider "must have" from "nice
>>>>> to
>>>>> have"), the current status of that content, target dates for the
>>>>> release,
>>>>> and the process that we plan to use to generate the release.
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>>
>>>>>
>>>>> Jeremy Hughes wrote:
>>>>>>
>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>
>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>> on the wiki.
>>>>>>
>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>> changed quite a bit :-)
>>>>>>
>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>
>>>>>>>> Jeremy
>>>>>>>>
>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>> 0.1
>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>
>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>> step
>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>
>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>
>>>>>>>>> --kevan
>>>>>>>>>
>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>
>>> --
>>> Joe
>>>
>>
>>
>>
>
>
> --
> Joe
>
Re: [DISCUSSION] Aries release
Posted by Alasdair Nottingham <no...@apache.org>.
Not that I'm aware of.
Alasdair
On 19 February 2010 14:38, Roland Huß <Ro...@consol.de> wrote:
> Just out of curiosity: Is there a way to get the updated EEG Spec
> (as a non OSGi member) ? As an early adaptor of the OSGi JMX API
> I'm really curious about the changes in it.
>
> ...roland
>
> On 19.02.2010, at 14:21, adam wojtuniak wrote:
>
>> About JMX:
>> API needs to be updated (I will start on that next week) cause its out of
>> date. When that will be done I don't see a problem to release JMX.
>> All the functionality from the spec will be there.
>> Requested improvements we can add with a new relaese.
>>
>> Cheers,
>> Adam
>>
>> On Fri, Feb 19, 2010 at 1:09 PM, Joe Bohn <jo...@gmail.com> wrote:
>>
>>> I'd also like to see us release the sample applications but I think there
>>> is at least one complication. Both Blog Sample and AriesTrader generate
>>> EBAs using different techniques - but both leverage the maven-antrun-plugin
>>> to finally produce a file of type "eba".
>>>
>>> I think the result is that the eba will not be available in a maven
>>> repository.
>>>
>>> One of the differences is that AriesTrader first generates a jar using the
>>> maven-assembly-plugin and then copies this to an eba. The jar will be
>>> managed by maven and IIUC it should be deployable as an "application" even
>>> with an extension of "jar" rather than "eba". If that is correct then
>>> perhaps delivery of an application jar is an acceptable approach for the 1st
>>> release. Unfortunately I haven't actually setup my equinox assembly to
>>> deploy the eba yet - it still deploys all of the individual bundles.
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>> Guillaume Nodet wrote:
>>>
>>>> I'd like to see at least those included:
>>>> * blueprint
>>>> * jmx
>>>> * jndi
>>>> * transaction
>>>>
>>>> I don't think applications are really usable yet and I haven't really
>>>> looked at JPA yet, so can't tell about it.
>>>> The transaction component is functional and we've been using it mostly
>>>> unchanged since a long time in ServiceMix.
>>>> Do you have any particular concerns with it ? (I'm not talking about
>>>> declarative transactions for blueprint, note).
>>>>
>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>
>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>> volunteering
>>>>> to be the release manager. Your response helps me get a better picture
>>>>> of
>>>>> the plans.
>>>>>
>>>>> I was really just interested in the general objectives and timing since
>>>>> it
>>>>> hadn't been discussed yet. To get the release out in Feb means it will
>>>>> be
>>>>> delivered next week. I'm afraid the hill might be a little too steep to
>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>
>>>>> The more communication the better. It's important to get everybody
>>>>> thinking
>>>>> and planning along the same lines (or understand quickly if there are any
>>>>> differences of opinion). Knowing that you are thinking of creating a
>>>>> release candidate next week means that we should be getting more
>>>>> restrictive
>>>>> on new content to avoid any unpleasant surprises.
>>>>>
>>>>> I don't have any strong opinions on what should be in or out - but in
>>>>> general it doesn't make sense to release things that aren't functional.
>>>>> At
>>>>> the moment I'm not sure what those are - but I suspect not all of the
>>>>> components are fully functional yet (for example transaction).
>>>>>
>>>>> Best Regards,
>>>>> Joe
>>>>>
>>>>>
>>>>> Jeremy Hughes wrote:
>>>>>
>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>>> vacation until monday.
>>>>>>
>>>>>> Personally, I think the 0.1 release should serve to get what we have
>>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>>> are to get the build in the right shape to create the distribution
>>>>>> files that are acceptable to the IPMC. I think each main area of the
>>>>>> code deserves at least a README to describe what's possible. Since
>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>> timing I hope/expect to get the release out this in feb. If there are
>>>>>> particular JIRAs or other issues you feel should be included please
>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>>> 0.2 version. WDYT?
>>>>>>
>>>>>> Cheers,
>>>>>> Jeremy
>>>>>>
>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>
>>>>>>> Jeremy,
>>>>>>>
>>>>>>> What are your current thoughts and goals regarding the release and
>>>>>>> potential
>>>>>>> target dates?
>>>>>>>
>>>>>>> I think it would be good if you could summarize your thoughts in an
>>>>>>> email
>>>>>>> or
>>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>>> progress.
>>>>>>> Of particular interest would be the content that we would like to see
>>>>>>> in
>>>>>>> the first release (clarifying what we consider "must have" from "nice
>>>>>>> to
>>>>>>> have"), the current status of that content, target dates for the
>>>>>>> release,
>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jeremy Hughes wrote:
>>>>>>>
>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>>>> on the wiki.
>>>>>>>>>
>>>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>>>> changed quite a bit :-)
>>>>>>>>
>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>
>>>>>>>>>> Jeremy
>>>>>>>>>>
>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>>>> 0.1
>>>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>>
>>>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>>>> step
>>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>>
>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>
>>>>>>>>>>> --kevan
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> Open Source SOA
>>>>>>>>> http://fusesource.com
>>>>>>>>>
>>>>>>>>> --
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Joe
>>>
>
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSSION] Aries release
Posted by David Bosschaert <da...@gmail.com>.
Hi Roland,
The 4.2 enterprise spec will be released next month, so I guess you
need a little more patience.
There is a public early access draft available, but some of the
details have changed in the ultimate spec. The early access draft is
here: http://www.osgi.org/download/osgi-4.2-enterprise-early-draft4.pdf
Best regards,
David
On 19 February 2010 14:38, Roland Huß <Ro...@consol.de> wrote:
> Just out of curiosity: Is there a way to get the updated EEG Spec
> (as a non OSGi member) ? As an early adaptor of the OSGi JMX API
> I'm really curious about the changes in it.
>
> ...roland
>
> On 19.02.2010, at 14:21, adam wojtuniak wrote:
>
>> About JMX:
>> API needs to be updated (I will start on that next week) cause its out of
>> date. When that will be done I don't see a problem to release JMX.
>> All the functionality from the spec will be there.
>> Requested improvements we can add with a new relaese.
>>
>> Cheers,
>> Adam
>>
>> On Fri, Feb 19, 2010 at 1:09 PM, Joe Bohn <jo...@gmail.com> wrote:
>>
>>> I'd also like to see us release the sample applications but I think there
>>> is at least one complication. Both Blog Sample and AriesTrader generate
>>> EBAs using different techniques - but both leverage the maven-antrun-plugin
>>> to finally produce a file of type "eba".
>>>
>>> I think the result is that the eba will not be available in a maven
>>> repository.
>>>
>>> One of the differences is that AriesTrader first generates a jar using the
>>> maven-assembly-plugin and then copies this to an eba. The jar will be
>>> managed by maven and IIUC it should be deployable as an "application" even
>>> with an extension of "jar" rather than "eba". If that is correct then
>>> perhaps delivery of an application jar is an acceptable approach for the 1st
>>> release. Unfortunately I haven't actually setup my equinox assembly to
>>> deploy the eba yet - it still deploys all of the individual bundles.
>>>
>>> Joe
>>>
>>>
>>>
>>>
>>> Guillaume Nodet wrote:
>>>
>>>> I'd like to see at least those included:
>>>> * blueprint
>>>> * jmx
>>>> * jndi
>>>> * transaction
>>>>
>>>> I don't think applications are really usable yet and I haven't really
>>>> looked at JPA yet, so can't tell about it.
>>>> The transaction component is functional and we've been using it mostly
>>>> unchanged since a long time in ServiceMix.
>>>> Do you have any particular concerns with it ? (I'm not talking about
>>>> declarative transactions for blueprint, note).
>>>>
>>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>>
>>>>> Thanks for the response (even while on vacation!) ... and for
>>>>> volunteering
>>>>> to be the release manager. Your response helps me get a better picture
>>>>> of
>>>>> the plans.
>>>>>
>>>>> I was really just interested in the general objectives and timing since
>>>>> it
>>>>> hadn't been discussed yet. To get the release out in Feb means it will
>>>>> be
>>>>> delivered next week. I'm afraid the hill might be a little too steep to
>>>>> climb that quickly but I'm happy to be proven wrong.
>>>>>
>>>>> The more communication the better. It's important to get everybody
>>>>> thinking
>>>>> and planning along the same lines (or understand quickly if there are any
>>>>> differences of opinion). Knowing that you are thinking of creating a
>>>>> release candidate next week means that we should be getting more
>>>>> restrictive
>>>>> on new content to avoid any unpleasant surprises.
>>>>>
>>>>> I don't have any strong opinions on what should be in or out - but in
>>>>> general it doesn't make sense to release things that aren't functional.
>>>>> At
>>>>> the moment I'm not sure what those are - but I suspect not all of the
>>>>> components are fully functional yet (for example transaction).
>>>>>
>>>>> Best Regards,
>>>>> Joe
>>>>>
>>>>>
>>>>> Jeremy Hughes wrote:
>>>>>
>>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>>> vacation until monday.
>>>>>>
>>>>>> Personally, I think the 0.1 release should serve to get what we have
>>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>>> are to get the build in the right shape to create the distribution
>>>>>> files that are acceptable to the IPMC. I think each main area of the
>>>>>> code deserves at least a README to describe what's possible. Since
>>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>>> timing I hope/expect to get the release out this in feb. If there are
>>>>>> particular JIRAs or other issues you feel should be included please
>>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>>> 0.2 version. WDYT?
>>>>>>
>>>>>> Cheers,
>>>>>> Jeremy
>>>>>>
>>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>>
>>>>>>> Jeremy,
>>>>>>>
>>>>>>> What are your current thoughts and goals regarding the release and
>>>>>>> potential
>>>>>>> target dates?
>>>>>>>
>>>>>>> I think it would be good if you could summarize your thoughts in an
>>>>>>> email
>>>>>>> or
>>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>>> progress.
>>>>>>> Of particular interest would be the content that we would like to see
>>>>>>> in
>>>>>>> the first release (clarifying what we consider "must have" from "nice
>>>>>>> to
>>>>>>> have"), the current status of that content, target dates for the
>>>>>>> release,
>>>>>>> and the process that we plan to use to generate the release.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Jeremy Hughes wrote:
>>>>>>>
>>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>>
>>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>>>> on the wiki.
>>>>>>>>>
>>>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>>>> changed quite a bit :-)
>>>>>>>>
>>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>>
>>>>>>>>>> Jeremy
>>>>>>>>>>
>>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>>>> 0.1
>>>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>>
>>>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>>>> step
>>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>>
>>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>>
>>>>>>>>>>> --kevan
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>> Cheers,
>>>>>>>>> Guillaume Nodet
>>>>>>>>> ------------------------
>>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>>> ------------------------
>>>>>>>>> Open Source SOA
>>>>>>>>> http://fusesource.com
>>>>>>>>>
>>>>>>>>> --
>>>>>>> Joe
>>>>>>>
>>>>>>>
>>>>> --
>>>>> Joe
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Joe
>>>
>
>
Re: [DISCUSSION] Aries release
Posted by Roland Huß <Ro...@consol.de>.
Just out of curiosity: Is there a way to get the updated EEG Spec
(as a non OSGi member) ? As an early adaptor of the OSGi JMX API
I'm really curious about the changes in it.
...roland
On 19.02.2010, at 14:21, adam wojtuniak wrote:
> About JMX:
> API needs to be updated (I will start on that next week) cause its out of
> date. When that will be done I don't see a problem to release JMX.
> All the functionality from the spec will be there.
> Requested improvements we can add with a new relaese.
>
> Cheers,
> Adam
>
> On Fri, Feb 19, 2010 at 1:09 PM, Joe Bohn <jo...@gmail.com> wrote:
>
>> I'd also like to see us release the sample applications but I think there
>> is at least one complication. Both Blog Sample and AriesTrader generate
>> EBAs using different techniques - but both leverage the maven-antrun-plugin
>> to finally produce a file of type "eba".
>>
>> I think the result is that the eba will not be available in a maven
>> repository.
>>
>> One of the differences is that AriesTrader first generates a jar using the
>> maven-assembly-plugin and then copies this to an eba. The jar will be
>> managed by maven and IIUC it should be deployable as an "application" even
>> with an extension of "jar" rather than "eba". If that is correct then
>> perhaps delivery of an application jar is an acceptable approach for the 1st
>> release. Unfortunately I haven't actually setup my equinox assembly to
>> deploy the eba yet - it still deploys all of the individual bundles.
>>
>> Joe
>>
>>
>>
>>
>> Guillaume Nodet wrote:
>>
>>> I'd like to see at least those included:
>>> * blueprint
>>> * jmx
>>> * jndi
>>> * transaction
>>>
>>> I don't think applications are really usable yet and I haven't really
>>> looked at JPA yet, so can't tell about it.
>>> The transaction component is functional and we've been using it mostly
>>> unchanged since a long time in ServiceMix.
>>> Do you have any particular concerns with it ? (I'm not talking about
>>> declarative transactions for blueprint, note).
>>>
>>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>>
>>>> Thanks for the response (even while on vacation!) ... and for
>>>> volunteering
>>>> to be the release manager. Your response helps me get a better picture
>>>> of
>>>> the plans.
>>>>
>>>> I was really just interested in the general objectives and timing since
>>>> it
>>>> hadn't been discussed yet. To get the release out in Feb means it will
>>>> be
>>>> delivered next week. I'm afraid the hill might be a little too steep to
>>>> climb that quickly but I'm happy to be proven wrong.
>>>>
>>>> The more communication the better. It's important to get everybody
>>>> thinking
>>>> and planning along the same lines (or understand quickly if there are any
>>>> differences of opinion). Knowing that you are thinking of creating a
>>>> release candidate next week means that we should be getting more
>>>> restrictive
>>>> on new content to avoid any unpleasant surprises.
>>>>
>>>> I don't have any strong opinions on what should be in or out - but in
>>>> general it doesn't make sense to release things that aren't functional.
>>>> At
>>>> the moment I'm not sure what those are - but I suspect not all of the
>>>> components are fully functional yet (for example transaction).
>>>>
>>>> Best Regards,
>>>> Joe
>>>>
>>>>
>>>> Jeremy Hughes wrote:
>>>>
>>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>>> vacation until monday.
>>>>>
>>>>> Personally, I think the 0.1 release should serve to get what we have
>>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>>> are to get the build in the right shape to create the distribution
>>>>> files that are acceptable to the IPMC. I think each main area of the
>>>>> code deserves at least a README to describe what's possible. Since
>>>>> this is the first release there are likely a few unknowns - w.r.t
>>>>> timing I hope/expect to get the release out this in feb. If there are
>>>>> particular JIRAs or other issues you feel should be included please
>>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>>> 0.2 version. WDYT?
>>>>>
>>>>> Cheers,
>>>>> Jeremy
>>>>>
>>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>>
>>>>>> Jeremy,
>>>>>>
>>>>>> What are your current thoughts and goals regarding the release and
>>>>>> potential
>>>>>> target dates?
>>>>>>
>>>>>> I think it would be good if you could summarize your thoughts in an
>>>>>> email
>>>>>> or
>>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>>> progress.
>>>>>> Of particular interest would be the content that we would like to see
>>>>>> in
>>>>>> the first release (clarifying what we consider "must have" from "nice
>>>>>> to
>>>>>> have"), the current status of that content, target dates for the
>>>>>> release,
>>>>>> and the process that we plan to use to generate the release.
>>>>>>
>>>>>> Thanks,
>>>>>> Joe
>>>>>>
>>>>>>
>>>>>>
>>>>>> Jeremy Hughes wrote:
>>>>>>
>>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>>
>>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>>> on the wiki.
>>>>>>>>
>>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>>> changed quite a bit :-)
>>>>>>>
>>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>>
>>>>>>>>> Jeremy
>>>>>>>>>
>>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>>> 0.1
>>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>>
>>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>>> step
>>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>>
>>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>>
>>>>>>>>>> --kevan
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>> Cheers,
>>>>>>>> Guillaume Nodet
>>>>>>>> ------------------------
>>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>>> ------------------------
>>>>>>>> Open Source SOA
>>>>>>>> http://fusesource.com
>>>>>>>>
>>>>>>>> --
>>>>>> Joe
>>>>>>
>>>>>>
>>>> --
>>>> Joe
>>>>
>>>>
>>>
>>>
>>>
>>
>> --
>> Joe
>>
Re: [DISCUSSION] Aries release
Posted by adam wojtuniak <ad...@gmail.com>.
About JMX:
API needs to be updated (I will start on that next week) cause its out of
date. When that will be done I don't see a problem to release JMX.
All the functionality from the spec will be there.
Requested improvements we can add with a new relaese.
Cheers,
Adam
On Fri, Feb 19, 2010 at 1:09 PM, Joe Bohn <jo...@gmail.com> wrote:
> I'd also like to see us release the sample applications but I think there
> is at least one complication. Both Blog Sample and AriesTrader generate
> EBAs using different techniques - but both leverage the maven-antrun-plugin
> to finally produce a file of type "eba".
>
> I think the result is that the eba will not be available in a maven
> repository.
>
> One of the differences is that AriesTrader first generates a jar using the
> maven-assembly-plugin and then copies this to an eba. The jar will be
> managed by maven and IIUC it should be deployable as an "application" even
> with an extension of "jar" rather than "eba". If that is correct then
> perhaps delivery of an application jar is an acceptable approach for the 1st
> release. Unfortunately I haven't actually setup my equinox assembly to
> deploy the eba yet - it still deploys all of the individual bundles.
>
> Joe
>
>
>
>
> Guillaume Nodet wrote:
>
>> I'd like to see at least those included:
>> * blueprint
>> * jmx
>> * jndi
>> * transaction
>>
>> I don't think applications are really usable yet and I haven't really
>> looked at JPA yet, so can't tell about it.
>> The transaction component is functional and we've been using it mostly
>> unchanged since a long time in ServiceMix.
>> Do you have any particular concerns with it ? (I'm not talking about
>> declarative transactions for blueprint, note).
>>
>> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>>
>>> Thanks for the response (even while on vacation!) ... and for
>>> volunteering
>>> to be the release manager. Your response helps me get a better picture
>>> of
>>> the plans.
>>>
>>> I was really just interested in the general objectives and timing since
>>> it
>>> hadn't been discussed yet. To get the release out in Feb means it will
>>> be
>>> delivered next week. I'm afraid the hill might be a little too steep to
>>> climb that quickly but I'm happy to be proven wrong.
>>>
>>> The more communication the better. It's important to get everybody
>>> thinking
>>> and planning along the same lines (or understand quickly if there are any
>>> differences of opinion). Knowing that you are thinking of creating a
>>> release candidate next week means that we should be getting more
>>> restrictive
>>> on new content to avoid any unpleasant surprises.
>>>
>>> I don't have any strong opinions on what should be in or out - but in
>>> general it doesn't make sense to release things that aren't functional.
>>> At
>>> the moment I'm not sure what those are - but I suspect not all of the
>>> components are fully functional yet (for example transaction).
>>>
>>> Best Regards,
>>> Joe
>>>
>>>
>>> Jeremy Hughes wrote:
>>>
>>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>>> vacation until monday.
>>>>
>>>> Personally, I think the 0.1 release should serve to get what we have
>>>> right now in the respectable form the ASF requires. So 'must haves'
>>>> are to get the build in the right shape to create the distribution
>>>> files that are acceptable to the IPMC. I think each main area of the
>>>> code deserves at least a README to describe what's possible. Since
>>>> this is the first release there are likely a few unknowns - w.r.t
>>>> timing I hope/expect to get the release out this in feb. If there are
>>>> particular JIRAs or other issues you feel should be included please
>>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>>> 0.2 version. WDYT?
>>>>
>>>> Cheers,
>>>> Jeremy
>>>>
>>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>>
>>>>> Jeremy,
>>>>>
>>>>> What are your current thoughts and goals regarding the release and
>>>>> potential
>>>>> target dates?
>>>>>
>>>>> I think it would be good if you could summarize your thoughts in an
>>>>> email
>>>>> or
>>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>>> progress.
>>>>> Of particular interest would be the content that we would like to see
>>>>> in
>>>>> the first release (clarifying what we consider "must have" from "nice
>>>>> to
>>>>> have"), the current status of that content, target dates for the
>>>>> release,
>>>>> and the process that we plan to use to generate the release.
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>>
>>>>>
>>>>> Jeremy Hughes wrote:
>>>>>
>>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>>
>>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>>> on the wiki.
>>>>>>>
>>>>>> Certainly will. It's been a while since I did one and the process has
>>>>>> changed quite a bit :-)
>>>>>>
>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>>
>>>>>>>> Jeremy
>>>>>>>>
>>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>>> 0.1
>>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>>
>>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>>> step
>>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>>
>>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>>
>>>>>>>>> --kevan
>>>>>>>>>
>>>>>>>>> --
>>>>>>> Cheers,
>>>>>>> Guillaume Nodet
>>>>>>> ------------------------
>>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>>> ------------------------
>>>>>>> Open Source SOA
>>>>>>> http://fusesource.com
>>>>>>>
>>>>>>> --
>>>>> Joe
>>>>>
>>>>>
>>> --
>>> Joe
>>>
>>>
>>
>>
>>
>
> --
> Joe
>
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
I'd also like to see us release the sample applications but I think
there is at least one complication. Both Blog Sample and AriesTrader
generate EBAs using different techniques - but both leverage the
maven-antrun-plugin to finally produce a file of type "eba".
I think the result is that the eba will not be available in a maven
repository.
One of the differences is that AriesTrader first generates a jar using
the maven-assembly-plugin and then copies this to an eba. The jar will
be managed by maven and IIUC it should be deployable as an "application"
even with an extension of "jar" rather than "eba". If that is correct
then perhaps delivery of an application jar is an acceptable approach
for the 1st release. Unfortunately I haven't actually setup my equinox
assembly to deploy the eba yet - it still deploys all of the individual
bundles.
Joe
Guillaume Nodet wrote:
> I'd like to see at least those included:
> * blueprint
> * jmx
> * jndi
> * transaction
>
> I don't think applications are really usable yet and I haven't really
> looked at JPA yet, so can't tell about it.
> The transaction component is functional and we've been using it mostly
> unchanged since a long time in ServiceMix.
> Do you have any particular concerns with it ? (I'm not talking about
> declarative transactions for blueprint, note).
>
> On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
>> Thanks for the response (even while on vacation!) ... and for volunteering
>> to be the release manager. Your response helps me get a better picture of
>> the plans.
>>
>> I was really just interested in the general objectives and timing since it
>> hadn't been discussed yet. To get the release out in Feb means it will be
>> delivered next week. I'm afraid the hill might be a little too steep to
>> climb that quickly but I'm happy to be proven wrong.
>>
>> The more communication the better. It's important to get everybody thinking
>> and planning along the same lines (or understand quickly if there are any
>> differences of opinion). Knowing that you are thinking of creating a
>> release candidate next week means that we should be getting more restrictive
>> on new content to avoid any unpleasant surprises.
>>
>> I don't have any strong opinions on what should be in or out - but in
>> general it doesn't make sense to release things that aren't functional. At
>> the moment I'm not sure what those are - but I suspect not all of the
>> components are fully functional yet (for example transaction).
>>
>> Best Regards,
>> Joe
>>
>>
>> Jeremy Hughes wrote:
>>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>>> vacation until monday.
>>>
>>> Personally, I think the 0.1 release should serve to get what we have
>>> right now in the respectable form the ASF requires. So 'must haves'
>>> are to get the build in the right shape to create the distribution
>>> files that are acceptable to the IPMC. I think each main area of the
>>> code deserves at least a README to describe what's possible. Since
>>> this is the first release there are likely a few unknowns - w.r.t
>>> timing I hope/expect to get the release out this in feb. If there are
>>> particular JIRAs or other issues you feel should be included please
>>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>>> 0.2 version. WDYT?
>>>
>>> Cheers,
>>> Jeremy
>>>
>>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>> Jeremy,
>>>>
>>>> What are your current thoughts and goals regarding the release and
>>>> potential
>>>> target dates?
>>>>
>>>> I think it would be good if you could summarize your thoughts in an email
>>>> or
>>>> perhaps on a page in the wiki that we can keep updated as we make
>>>> progress.
>>>> Of particular interest would be the content that we would like to see in
>>>> the first release (clarifying what we consider "must have" from "nice to
>>>> have"), the current status of that content, target dates for the release,
>>>> and the process that we plan to use to generate the release.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>>
>>>>
>>>> Jeremy Hughes wrote:
>>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>>> I guess if you take some notes, it would be interesting to put those
>>>>>> on the wiki.
>>>>> Certainly will. It's been a while since I did one and the process has
>>>>> changed quite a bit :-)
>>>>>
>>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>>> wrote:
>>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>>
>>>>>>> Jeremy
>>>>>>>
>>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>>> 0.1
>>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>>
>>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>>> step
>>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>>
>>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>>
>>>>>>>> --kevan
>>>>>>>>
>>>>>> --
>>>>>> Cheers,
>>>>>> Guillaume Nodet
>>>>>> ------------------------
>>>>>> Blog: http://gnodet.blogspot.com/
>>>>>> ------------------------
>>>>>> Open Source SOA
>>>>>> http://fusesource.com
>>>>>>
>>>> --
>>>> Joe
>>>>
>>
>> --
>> Joe
>>
>
>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Guillaume Nodet <gn...@gmail.com>.
I'd like to see at least those included:
* blueprint
* jmx
* jndi
* transaction
I don't think applications are really usable yet and I haven't really
looked at JPA yet, so can't tell about it.
The transaction component is functional and we've been using it mostly
unchanged since a long time in ServiceMix.
Do you have any particular concerns with it ? (I'm not talking about
declarative transactions for blueprint, note).
On Fri, Feb 19, 2010 at 04:19, Joe Bohn <jo...@gmail.com> wrote:
> Thanks for the response (even while on vacation!) ... and for volunteering
> to be the release manager. Your response helps me get a better picture of
> the plans.
>
> I was really just interested in the general objectives and timing since it
> hadn't been discussed yet. To get the release out in Feb means it will be
> delivered next week. I'm afraid the hill might be a little too steep to
> climb that quickly but I'm happy to be proven wrong.
>
> The more communication the better. It's important to get everybody thinking
> and planning along the same lines (or understand quickly if there are any
> differences of opinion). Knowing that you are thinking of creating a
> release candidate next week means that we should be getting more restrictive
> on new content to avoid any unpleasant surprises.
>
> I don't have any strong opinions on what should be in or out - but in
> general it doesn't make sense to release things that aren't functional. At
> the moment I'm not sure what those are - but I suspect not all of the
> components are fully functional yet (for example transaction).
>
> Best Regards,
> Joe
>
>
> Jeremy Hughes wrote:
>>
>> Hi Joe, sorry I started setting myself up tuesday but am now out on
>> vacation until monday.
>>
>> Personally, I think the 0.1 release should serve to get what we have
>> right now in the respectable form the ASF requires. So 'must haves'
>> are to get the build in the right shape to create the distribution
>> files that are acceptable to the IPMC. I think each main area of the
>> code deserves at least a README to describe what's possible. Since
>> this is the first release there are likely a few unknowns - w.r.t
>> timing I hope/expect to get the release out this in feb. If there are
>> particular JIRAs or other issues you feel should be included please
>> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
>> issues for 0.1 appropriately and issues not for 0.1 to target a new
>> 0.2 version. WDYT?
>>
>> Cheers,
>> Jeremy
>>
>> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>>>
>>> Jeremy,
>>>
>>> What are your current thoughts and goals regarding the release and
>>> potential
>>> target dates?
>>>
>>> I think it would be good if you could summarize your thoughts in an email
>>> or
>>> perhaps on a page in the wiki that we can keep updated as we make
>>> progress.
>>> Of particular interest would be the content that we would like to see in
>>> the first release (clarifying what we consider "must have" from "nice to
>>> have"), the current status of that content, target dates for the release,
>>> and the process that we plan to use to generate the release.
>>>
>>> Thanks,
>>> Joe
>>>
>>>
>>>
>>> Jeremy Hughes wrote:
>>>>
>>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>>>
>>>>> Great, thanks a lot. Let us know if you need any help.
>>>>> I guess if you take some notes, it would be interesting to put those
>>>>> on the wiki.
>>>>
>>>> Certainly will. It's been a while since I did one and the process has
>>>> changed quite a bit :-)
>>>>
>>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>>
>>>>>> Jeremy
>>>>>>
>>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Sounds like the consensus is for a release with all components at a
>>>>>>> 0.1
>>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>>
>>>>>>> Showing the ability to generate an Apache release is an important
>>>>>>> step
>>>>>>> for the community. Would definitely like to see this happen...
>>>>>>>
>>>>>>> We'll need a release manager. Any volunteers?
>>>>>>>
>>>>>>> --kevan
>>>>>>>
>>>>>
>>>>> --
>>>>> Cheers,
>>>>> Guillaume Nodet
>>>>> ------------------------
>>>>> Blog: http://gnodet.blogspot.com/
>>>>> ------------------------
>>>>> Open Source SOA
>>>>> http://fusesource.com
>>>>>
>>>
>>> --
>>> Joe
>>>
>>
>
>
> --
> Joe
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
Thanks for the response (even while on vacation!) ... and for
volunteering to be the release manager. Your response helps me get a
better picture of the plans.
I was really just interested in the general objectives and timing since
it hadn't been discussed yet. To get the release out in Feb means it
will be delivered next week. I'm afraid the hill might be a little too
steep to climb that quickly but I'm happy to be proven wrong.
The more communication the better. It's important to get everybody
thinking and planning along the same lines (or understand quickly if
there are any differences of opinion). Knowing that you are thinking of
creating a release candidate next week means that we should be getting
more restrictive on new content to avoid any unpleasant surprises.
I don't have any strong opinions on what should be in or out - but in
general it doesn't make sense to release things that aren't functional.
At the moment I'm not sure what those are - but I suspect not all of the
components are fully functional yet (for example transaction).
Best Regards,
Joe
Jeremy Hughes wrote:
> Hi Joe, sorry I started setting myself up tuesday but am now out on
> vacation until monday.
>
> Personally, I think the 0.1 release should serve to get what we have
> right now in the respectable form the ASF requires. So 'must haves'
> are to get the build in the right shape to create the distribution
> files that are acceptable to the IPMC. I think each main area of the
> code deserves at least a README to describe what's possible. Since
> this is the first release there are likely a few unknowns - w.r.t
> timing I hope/expect to get the release out this in feb. If there are
> particular JIRAs or other issues you feel should be included please
> say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
> issues for 0.1 appropriately and issues not for 0.1 to target a new
> 0.2 version. WDYT?
>
> Cheers,
> Jeremy
>
> On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
>> Jeremy,
>>
>> What are your current thoughts and goals regarding the release and potential
>> target dates?
>>
>> I think it would be good if you could summarize your thoughts in an email or
>> perhaps on a page in the wiki that we can keep updated as we make progress.
>> Of particular interest would be the content that we would like to see in
>> the first release (clarifying what we consider "must have" from "nice to
>> have"), the current status of that content, target dates for the release,
>> and the process that we plan to use to generate the release.
>>
>> Thanks,
>> Joe
>>
>>
>>
>> Jeremy Hughes wrote:
>>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>> Great, thanks a lot. Let us know if you need any help.
>>>> I guess if you take some notes, it would be interesting to put those
>>>> on the wiki.
>>> Certainly will. It's been a while since I did one and the process has
>>> changed quite a bit :-)
>>>
>>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org> wrote:
>>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>>
>>>>> Jeremy
>>>>>
>>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com> wrote:
>>>>>> Sounds like the consensus is for a release with all components at a 0.1
>>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>>
>>>>>> Showing the ability to generate an Apache release is an important step
>>>>>> for the community. Would definitely like to see this happen...
>>>>>>
>>>>>> We'll need a release manager. Any volunteers?
>>>>>>
>>>>>> --kevan
>>>>>>
>>>>
>>>> --
>>>> Cheers,
>>>> Guillaume Nodet
>>>> ------------------------
>>>> Blog: http://gnodet.blogspot.com/
>>>> ------------------------
>>>> Open Source SOA
>>>> http://fusesource.com
>>>>
>>
>> --
>> Joe
>>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
Hi Joe, sorry I started setting myself up tuesday but am now out on
vacation until monday.
Personally, I think the 0.1 release should serve to get what we have
right now in the respectable form the ASF requires. So 'must haves'
are to get the build in the right shape to create the distribution
files that are acceptable to the IPMC. I think each main area of the
code deserves at least a README to describe what's possible. Since
this is the first release there are likely a few unknowns - w.r.t
timing I hope/expect to get the release out this in feb. If there are
particular JIRAs or other issues you feel should be included please
say. I'd like to rename the current JIRA version 1.0 to 0.1 and target
issues for 0.1 appropriately and issues not for 0.1 to target a new
0.2 version. WDYT?
Cheers,
Jeremy
On 18 February 2010 15:39, Joe Bohn <jo...@gmail.com> wrote:
> Jeremy,
>
> What are your current thoughts and goals regarding the release and potential
> target dates?
>
> I think it would be good if you could summarize your thoughts in an email or
> perhaps on a page in the wiki that we can keep updated as we make progress.
> Of particular interest would be the content that we would like to see in
> the first release (clarifying what we consider "must have" from "nice to
> have"), the current status of that content, target dates for the release,
> and the process that we plan to use to generate the release.
>
> Thanks,
> Joe
>
>
>
> Jeremy Hughes wrote:
>>
>> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>>>
>>> Great, thanks a lot. Let us know if you need any help.
>>> I guess if you take some notes, it would be interesting to put those
>>> on the wiki.
>>
>> Certainly will. It's been a while since I did one and the process has
>> changed quite a bit :-)
>>
>>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org> wrote:
>>>>
>>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>>
>>>> Jeremy
>>>>
>>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com> wrote:
>>>>>
>>>>> Sounds like the consensus is for a release with all components at a 0.1
>>>>> version number. Best to start with a simple versioning scheme, IMO.
>>>>> Personally, I don't view a 0.1 blueprint release as an issue.
>>>>>
>>>>> Showing the ability to generate an Apache release is an important step
>>>>> for the community. Would definitely like to see this happen...
>>>>>
>>>>> We'll need a release manager. Any volunteers?
>>>>>
>>>>> --kevan
>>>>>
>>>
>>>
>>> --
>>> Cheers,
>>> Guillaume Nodet
>>> ------------------------
>>> Blog: http://gnodet.blogspot.com/
>>> ------------------------
>>> Open Source SOA
>>> http://fusesource.com
>>>
>>
>
>
> --
> Joe
>
Re: [DISCUSSION] Aries release
Posted by Joe Bohn <jo...@gmail.com>.
Jeremy,
What are your current thoughts and goals regarding the release and
potential target dates?
I think it would be good if you could summarize your thoughts in an
email or perhaps on a page in the wiki that we can keep updated as we
make progress. Of particular interest would be the content that we
would like to see in the first release (clarifying what we consider
"must have" from "nice to have"), the current status of that content,
target dates for the release, and the process that we plan to use to
generate the release.
Thanks,
Joe
Jeremy Hughes wrote:
> On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
>> Great, thanks a lot. Let us know if you need any help.
>> I guess if you take some notes, it would be interesting to put those
>> on the wiki.
>
> Certainly will. It's been a while since I did one and the process has
> changed quite a bit :-)
>
>> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org> wrote:
>>> Hi Kevan, thanks. I volunteer to be release manager.
>>>
>>> Jeremy
>>>
>>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com> wrote:
>>>> Sounds like the consensus is for a release with all components at a 0.1 version number. Best to start with a simple versioning scheme, IMO. Personally, I don't view a 0.1 blueprint release as an issue.
>>>>
>>>> Showing the ability to generate an Apache release is an important step for the community. Would definitely like to see this happen...
>>>>
>>>> We'll need a release manager. Any volunteers?
>>>>
>>>> --kevan
>>>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
--
Joe
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
On 12 February 2010 09:39, Guillaume Nodet <gn...@gmail.com> wrote:
> Great, thanks a lot. Let us know if you need any help.
> I guess if you take some notes, it would be interesting to put those
> on the wiki.
Certainly will. It's been a while since I did one and the process has
changed quite a bit :-)
>
> On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org> wrote:
>> Hi Kevan, thanks. I volunteer to be release manager.
>>
>> Jeremy
>>
>> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com> wrote:
>>> Sounds like the consensus is for a release with all components at a 0.1 version number. Best to start with a simple versioning scheme, IMO. Personally, I don't view a 0.1 blueprint release as an issue.
>>>
>>> Showing the ability to generate an Apache release is an important step for the community. Would definitely like to see this happen...
>>>
>>> We'll need a release manager. Any volunteers?
>>>
>>> --kevan
>>>
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Re: [DISCUSSION] Aries release
Posted by Guillaume Nodet <gn...@gmail.com>.
Great, thanks a lot. Let us know if you need any help.
I guess if you take some notes, it would be interesting to put those
on the wiki.
On Fri, Feb 12, 2010 at 10:32, Jeremy Hughes <hu...@apache.org> wrote:
> Hi Kevan, thanks. I volunteer to be release manager.
>
> Jeremy
>
> On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com> wrote:
>> Sounds like the consensus is for a release with all components at a 0.1 version number. Best to start with a simple versioning scheme, IMO. Personally, I don't view a 0.1 blueprint release as an issue.
>>
>> Showing the ability to generate an Apache release is an important step for the community. Would definitely like to see this happen...
>>
>> We'll need a release manager. Any volunteers?
>>
>> --kevan
>>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Aries release
Posted by Jeremy Hughes <hu...@apache.org>.
Hi Kevan, thanks. I volunteer to be release manager.
Jeremy
On 11 February 2010 16:38, Kevan Miller <ke...@gmail.com> wrote:
> Sounds like the consensus is for a release with all components at a 0.1 version number. Best to start with a simple versioning scheme, IMO. Personally, I don't view a 0.1 blueprint release as an issue.
>
> Showing the ability to generate an Apache release is an important step for the community. Would definitely like to see this happen...
>
> We'll need a release manager. Any volunteers?
>
> --kevan
>
Re: [DISCUSSION] Aries release
Posted by Kevan Miller <ke...@gmail.com>.
Sounds like the consensus is for a release with all components at a 0.1 version number. Best to start with a simple versioning scheme, IMO. Personally, I don't view a 0.1 blueprint release as an issue.
Showing the ability to generate an Apache release is an important step for the community. Would definitely like to see this happen...
We'll need a release manager. Any volunteers?
--kevan
Re: [DISCUSSION] Aries release
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
I think that it will be odd to release 0.1 of blueprint. JMHO but I
won't mind if we release everything together as v0.1.
Regards,
Alan
On Jan 27, 2010, at 9:16 AM, Guillaume Nodet wrote:
> I think it would seem more natural to have a single version across the
> components if we will always release those together. Having different
> versions only makes sense if these components are released
> independently.
> I've seen both happen in different projects. It seems that having a
> single version / release makes our life and our users' life easier
> (only one version to remember / upgrade, a single release to do). It
> would also enable us to provide a binary distribution, but it somewhat
> makes the release cycle longer as all components need to be ready. I
> don't really have a strong opinion on that, but i'd rather start with
> a single release and later switch to multiple versions if needed.
>
> On Wed, Jan 27, 2010 at 17:58, Alasdair Nottingham <no...@apache.org>
> wrote:
>> I think the only component in aries I think could be marked as 1.0 in
>> the first release is the blueprint component. However I would like to
>> see a discussion about how versioning works, whether we keep it in
>> lock step or independently versioned, and linked to this whether the
>> sub-components can be released independently of each other before we
>> ship blueprint at 1.0 and everything else at 0.1
>>
>> I don't know how long this discussion would take, but I wouldn't want
>> to hold up a first release for a long time to have the discussion
>> since it only affects a single component at this time.
>>
>> Thoughts?
>> Alasdair
>>
>> 2010/1/27 Alan D. Cabrera <li...@toolazydogs.com>:
>>>
>>> On Jan 27, 2010, at 3:45 AM, Alasdair Nottingham wrote:
>>>
>>>> I would not like to do a 1.0 release of components that implement
>>>> an
>>>> OSGi spec, but have not passed compliance. Since a lot of the
>>>> specifications are not yet final we should not be releasing 1.0
>>>> implementations of those specification.
>>>
>>> Makes sense to me.
>>>
>>>> This doesn't apply to blueprint since the spec is final, but for
>>>> the
>>>> other components I think we should stick with 0.1 for now. I do not
>>>> have a strong opinion on using separate versioning for the
>>>> components
>>>> right now, but I do think it might make sense for our first
>>>> release to
>>>> be consistent across components.
>>>
>>> So for blueprint it should be 1.0 and the others 0.1?
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>>
>>>> Alasdair
>>>>
>>>> 2010/1/27 Alan D. Cabrera <li...@toolazydogs.com>:
>>>>>
>>>>> On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
>>>>>
>>>>>> There's been a lot of activity lately so I'd like to propose we
>>>>>> do a
>>>>>> release so we can get some wider user feedback. I think we
>>>>>> should give
>>>>>> it a version of 0.1 and stick to versions <1 while we're in the
>>>>>> Incubator.
>>>>>
>>>>> I'm in favor of a release but prefer to call it 1.0. Why does
>>>>> it matter
>>>>> that we're in the incubator? Just curious.
>>>>>
>>>>>> Then there is the question of whether to independently version
>>>>>> the
>>>>>> high level modules or keep them lock-step. For now I think we
>>>>>> should
>>>>>> keep them lock-step until we feel a need to change that.
>>>>>
>>>>> I think that there's a strong chance that we will have patch
>>>>> releases
>>>>> that
>>>>> would affect only one module. I think it would be odd and
>>>>> confusing if
>>>>> the
>>>>> versions for the other modules were incremented as well,
>>>>> especially since
>>>>> not all the modules will always be consumed together.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Alan
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Alasdair Nottingham
>>>> not@apache.org
>>>
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
Re: [DISCUSSION] Aries release
Posted by Guillaume Nodet <gn...@gmail.com>.
I think it would seem more natural to have a single version across the
components if we will always release those together. Having different
versions only makes sense if these components are released
independently.
I've seen both happen in different projects. It seems that having a
single version / release makes our life and our users' life easier
(only one version to remember / upgrade, a single release to do). It
would also enable us to provide a binary distribution, but it somewhat
makes the release cycle longer as all components need to be ready. I
don't really have a strong opinion on that, but i'd rather start with
a single release and later switch to multiple versions if needed.
On Wed, Jan 27, 2010 at 17:58, Alasdair Nottingham <no...@apache.org> wrote:
> I think the only component in aries I think could be marked as 1.0 in
> the first release is the blueprint component. However I would like to
> see a discussion about how versioning works, whether we keep it in
> lock step or independently versioned, and linked to this whether the
> sub-components can be released independently of each other before we
> ship blueprint at 1.0 and everything else at 0.1
>
> I don't know how long this discussion would take, but I wouldn't want
> to hold up a first release for a long time to have the discussion
> since it only affects a single component at this time.
>
> Thoughts?
> Alasdair
>
> 2010/1/27 Alan D. Cabrera <li...@toolazydogs.com>:
>>
>> On Jan 27, 2010, at 3:45 AM, Alasdair Nottingham wrote:
>>
>>> I would not like to do a 1.0 release of components that implement an
>>> OSGi spec, but have not passed compliance. Since a lot of the
>>> specifications are not yet final we should not be releasing 1.0
>>> implementations of those specification.
>>
>> Makes sense to me.
>>
>>> This doesn't apply to blueprint since the spec is final, but for the
>>> other components I think we should stick with 0.1 for now. I do not
>>> have a strong opinion on using separate versioning for the components
>>> right now, but I do think it might make sense for our first release to
>>> be consistent across components.
>>
>> So for blueprint it should be 1.0 and the others 0.1?
>>
>>
>> Regards,
>> Alan
>>
>>>
>>> Alasdair
>>>
>>> 2010/1/27 Alan D. Cabrera <li...@toolazydogs.com>:
>>>>
>>>> On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
>>>>
>>>>> There's been a lot of activity lately so I'd like to propose we do a
>>>>> release so we can get some wider user feedback. I think we should give
>>>>> it a version of 0.1 and stick to versions <1 while we're in the
>>>>> Incubator.
>>>>
>>>> I'm in favor of a release but prefer to call it 1.0. Why does it matter
>>>> that we're in the incubator? Just curious.
>>>>
>>>>> Then there is the question of whether to independently version the
>>>>> high level modules or keep them lock-step. For now I think we should
>>>>> keep them lock-step until we feel a need to change that.
>>>>
>>>> I think that there's a strong chance that we will have patch releases
>>>> that
>>>> would affect only one module. I think it would be odd and confusing if
>>>> the
>>>> versions for the other modules were incremented as well, especially since
>>>> not all the modules will always be consumed together.
>>>>
>>>>
>>>> Regards,
>>>> Alan
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Alasdair Nottingham
>>> not@apache.org
>>
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [DISCUSSION] Aries release
Posted by Alasdair Nottingham <no...@apache.org>.
I think the only component in aries I think could be marked as 1.0 in
the first release is the blueprint component. However I would like to
see a discussion about how versioning works, whether we keep it in
lock step or independently versioned, and linked to this whether the
sub-components can be released independently of each other before we
ship blueprint at 1.0 and everything else at 0.1
I don't know how long this discussion would take, but I wouldn't want
to hold up a first release for a long time to have the discussion
since it only affects a single component at this time.
Thoughts?
Alasdair
2010/1/27 Alan D. Cabrera <li...@toolazydogs.com>:
>
> On Jan 27, 2010, at 3:45 AM, Alasdair Nottingham wrote:
>
>> I would not like to do a 1.0 release of components that implement an
>> OSGi spec, but have not passed compliance. Since a lot of the
>> specifications are not yet final we should not be releasing 1.0
>> implementations of those specification.
>
> Makes sense to me.
>
>> This doesn't apply to blueprint since the spec is final, but for the
>> other components I think we should stick with 0.1 for now. I do not
>> have a strong opinion on using separate versioning for the components
>> right now, but I do think it might make sense for our first release to
>> be consistent across components.
>
> So for blueprint it should be 1.0 and the others 0.1?
>
>
> Regards,
> Alan
>
>>
>> Alasdair
>>
>> 2010/1/27 Alan D. Cabrera <li...@toolazydogs.com>:
>>>
>>> On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
>>>
>>>> There's been a lot of activity lately so I'd like to propose we do a
>>>> release so we can get some wider user feedback. I think we should give
>>>> it a version of 0.1 and stick to versions <1 while we're in the
>>>> Incubator.
>>>
>>> I'm in favor of a release but prefer to call it 1.0. Why does it matter
>>> that we're in the incubator? Just curious.
>>>
>>>> Then there is the question of whether to independently version the
>>>> high level modules or keep them lock-step. For now I think we should
>>>> keep them lock-step until we feel a need to change that.
>>>
>>> I think that there's a strong chance that we will have patch releases
>>> that
>>> would affect only one module. I think it would be odd and confusing if
>>> the
>>> versions for the other modules were incremented as well, especially since
>>> not all the modules will always be consumed together.
>>>
>>>
>>> Regards,
>>> Alan
>>>
>>>
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSSION] Aries release
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 27, 2010, at 3:45 AM, Alasdair Nottingham wrote:
> I would not like to do a 1.0 release of components that implement an
> OSGi spec, but have not passed compliance. Since a lot of the
> specifications are not yet final we should not be releasing 1.0
> implementations of those specification.
Makes sense to me.
> This doesn't apply to blueprint since the spec is final, but for the
> other components I think we should stick with 0.1 for now. I do not
> have a strong opinion on using separate versioning for the components
> right now, but I do think it might make sense for our first release to
> be consistent across components.
So for blueprint it should be 1.0 and the others 0.1?
Regards,
Alan
>
> Alasdair
>
> 2010/1/27 Alan D. Cabrera <li...@toolazydogs.com>:
>>
>> On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
>>
>>> There's been a lot of activity lately so I'd like to propose we do a
>>> release so we can get some wider user feedback. I think we should
>>> give
>>> it a version of 0.1 and stick to versions <1 while we're in the
>>> Incubator.
>>
>> I'm in favor of a release but prefer to call it 1.0. Why does it
>> matter
>> that we're in the incubator? Just curious.
>>
>>> Then there is the question of whether to independently version the
>>> high level modules or keep them lock-step. For now I think we should
>>> keep them lock-step until we feel a need to change that.
>>
>> I think that there's a strong chance that we will have patch
>> releases that
>> would affect only one module. I think it would be odd and
>> confusing if the
>> versions for the other modules were incremented as well, especially
>> since
>> not all the modules will always be consumed together.
>>
>>
>> Regards,
>> Alan
>>
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
Re: [DISCUSSION] Aries release
Posted by Alasdair Nottingham <no...@apache.org>.
I would not like to do a 1.0 release of components that implement an
OSGi spec, but have not passed compliance. Since a lot of the
specifications are not yet final we should not be releasing 1.0
implementations of those specification.
This doesn't apply to blueprint since the spec is final, but for the
other components I think we should stick with 0.1 for now. I do not
have a strong opinion on using separate versioning for the components
right now, but I do think it might make sense for our first release to
be consistent across components.
Alasdair
2010/1/27 Alan D. Cabrera <li...@toolazydogs.com>:
>
> On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
>
>> There's been a lot of activity lately so I'd like to propose we do a
>> release so we can get some wider user feedback. I think we should give
>> it a version of 0.1 and stick to versions <1 while we're in the
>> Incubator.
>
> I'm in favor of a release but prefer to call it 1.0. Why does it matter
> that we're in the incubator? Just curious.
>
>> Then there is the question of whether to independently version the
>> high level modules or keep them lock-step. For now I think we should
>> keep them lock-step until we feel a need to change that.
>
> I think that there's a strong chance that we will have patch releases that
> would affect only one module. I think it would be odd and confusing if the
> versions for the other modules were incremented as well, especially since
> not all the modules will always be consumed together.
>
>
> Regards,
> Alan
>
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSSION] Aries release
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
> There's been a lot of activity lately so I'd like to propose we do a
> release so we can get some wider user feedback. I think we should give
> it a version of 0.1 and stick to versions <1 while we're in the
> Incubator.
I'm in favor of a release but prefer to call it 1.0. Why does it
matter that we're in the incubator? Just curious.
> Then there is the question of whether to independently version the
> high level modules or keep them lock-step. For now I think we should
> keep them lock-step until we feel a need to change that.
I think that there's a strong chance that we will have patch releases
that would affect only one module. I think it would be odd and
confusing if the versions for the other modules were incremented as
well, especially since not all the modules will always be consumed
together.
Regards,
Alan
Re: [DISCUSSION] Aries release
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Fri, Jan 29, 2010 at 9:55 AM, Charles Moulliard <cm...@gmail.com> wrote:
> Remark : Alternative is to wait IBM Redbook ;-)
Interesting...is one being written or just planned? That'd be an
excellent approach to get involved (and be paid :))
Jacek
--
Jacek Laskowski
Notatnik Projektanta Java EE - http://wszystkojawne.pl
p.s. Szukam speca/firmy od grafiki/CSS/HTML
Re: [DISCUSSION] Aries release
Posted by Charles Moulliard <cm...@gmail.com>.
Hi,
I have created a JIRA ticket concerning doc improvement :
https://issues.apache.org/jira/browse/ARIES-132
Remark : Alternative is to wait IBM Redbook ;-)
Regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard
Linkedlin : http://www.linkedin.com/in/charlesmoulliard
Apache Camel Group :
http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
On Thu, Jan 28, 2010 at 11:52 AM, zoe slattery
<zo...@googlemail.com>wrote:
> Charles Moulliard wrote:
>
>> I would like to suggest that the documentation of the web site is updated
>> in
>> pararrel of making a realese. A tutorial is available for Blueprint but
>> few
>> info or nothing concerning JNDI (publising and retrieving a OSGI service
>> (or
>> blueprint service), JPA, Transaction and Web (@Resource, packaging).
>>
>>
> Strongly agree. Specifically the blueprint tutorial is out of date
> (ARIES-93), the blog sample needs documentation (ARIES-103). I suggest we
> raise JIRAs for missing/inadequate docs and gate a release on resolving
> them.
>
> Zoe
>
> Kind Regards,
>>
>>
>> Charles Moulliard
>> Senior Enterprise Architect
>> Apache Camel Committer
>>
>> *****************************
>> blog : http://cmoulliard.blogspot.com
>> twitter : http://twitter.com/cmoulliard
>> Linkedlin : http://www.linkedin.com/in/charlesmoulliard
>>
>> Apache Camel Group :
>> http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
>>
>>
>> On Wed, Jan 27, 2010 at 11:37 AM, Valentin Mahrwald <
>> vmahrwald@googlemail.com> wrote:
>>
>>
>>
>>> +1 for doing a release.
>>>
>>> As for the release version number, would this have any bearing on how we
>>> version our package exports and bundles?
>>>
>>> Regards,
>>>
>>> Valentin
>>>
>>> On 26 Jan 2010, at 17:34, Jeremy Hughes wrote:
>>>
>>> There's been a lot of activity lately so I'd like to propose we do a
>>>
>>>
>>>> release so we can get some wider user feedback. I think we should give
>>>> it a version of 0.1 and stick to versions <1 while we're in the
>>>> Incubator.
>>>>
>>>> Then there is the question of whether to independently version the
>>>> high level modules or keep them lock-step. For now I think we should
>>>> keep them lock-step until we feel a need to change that.
>>>>
>>>> What does everyone think?
>>>>
>>>> Thanks,
>>>> Jeremy
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
Re: [DISCUSSION] Aries release
Posted by zoe slattery <zo...@googlemail.com>.
Charles Moulliard wrote:
> I would like to suggest that the documentation of the web site is updated in
> pararrel of making a realese. A tutorial is available for Blueprint but few
> info or nothing concerning JNDI (publising and retrieving a OSGI service (or
> blueprint service), JPA, Transaction and Web (@Resource, packaging).
>
Strongly agree. Specifically the blueprint tutorial is out of date
(ARIES-93), the blog sample needs documentation (ARIES-103). I suggest
we raise JIRAs for missing/inadequate docs and gate a release on
resolving them.
Zoe
> Kind Regards,
>
> Charles Moulliard
> Senior Enterprise Architect
> Apache Camel Committer
>
> *****************************
> blog : http://cmoulliard.blogspot.com
> twitter : http://twitter.com/cmoulliard
> Linkedlin : http://www.linkedin.com/in/charlesmoulliard
>
> Apache Camel Group :
> http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
>
>
> On Wed, Jan 27, 2010 at 11:37 AM, Valentin Mahrwald <
> vmahrwald@googlemail.com> wrote:
>
>
>> +1 for doing a release.
>>
>> As for the release version number, would this have any bearing on how we
>> version our package exports and bundles?
>>
>> Regards,
>>
>> Valentin
>>
>> On 26 Jan 2010, at 17:34, Jeremy Hughes wrote:
>>
>> There's been a lot of activity lately so I'd like to propose we do a
>>
>>> release so we can get some wider user feedback. I think we should give
>>> it a version of 0.1 and stick to versions <1 while we're in the
>>> Incubator.
>>>
>>> Then there is the question of whether to independently version the
>>> high level modules or keep them lock-step. For now I think we should
>>> keep them lock-step until we feel a need to change that.
>>>
>>> What does everyone think?
>>>
>>> Thanks,
>>> Jeremy
>>>
>>>
>>
>
>
Re: [DISCUSSION] Aries release
Posted by Charles Moulliard <cm...@gmail.com>.
I would like to suggest that the documentation of the web site is updated in
pararrel of making a realese. A tutorial is available for Blueprint but few
info or nothing concerning JNDI (publising and retrieving a OSGI service (or
blueprint service), JPA, Transaction and Web (@Resource, packaging).
Kind Regards,
Charles Moulliard
Senior Enterprise Architect
Apache Camel Committer
*****************************
blog : http://cmoulliard.blogspot.com
twitter : http://twitter.com/cmoulliard
Linkedlin : http://www.linkedin.com/in/charlesmoulliard
Apache Camel Group :
http://www.linkedin.com/groups?home=&gid=2447439&trk=anet_ug_hm
On Wed, Jan 27, 2010 at 11:37 AM, Valentin Mahrwald <
vmahrwald@googlemail.com> wrote:
> +1 for doing a release.
>
> As for the release version number, would this have any bearing on how we
> version our package exports and bundles?
>
> Regards,
>
> Valentin
>
> On 26 Jan 2010, at 17:34, Jeremy Hughes wrote:
>
> There's been a lot of activity lately so I'd like to propose we do a
>> release so we can get some wider user feedback. I think we should give
>> it a version of 0.1 and stick to versions <1 while we're in the
>> Incubator.
>>
>> Then there is the question of whether to independently version the
>> high level modules or keep them lock-step. For now I think we should
>> keep them lock-step until we feel a need to change that.
>>
>> What does everyone think?
>>
>> Thanks,
>> Jeremy
>>
>
>
Re: [DISCUSSION] Aries release
Posted by Valentin Mahrwald <vm...@googlemail.com>.
+1 for doing a release.
As for the release version number, would this have any bearing on how
we version our package exports and bundles?
Regards,
Valentin
On 26 Jan 2010, at 17:34, Jeremy Hughes wrote:
> There's been a lot of activity lately so I'd like to propose we do a
> release so we can get some wider user feedback. I think we should give
> it a version of 0.1 and stick to versions <1 while we're in the
> Incubator.
>
> Then there is the question of whether to independently version the
> high level modules or keep them lock-step. For now I think we should
> keep them lock-step until we feel a need to change that.
>
> What does everyone think?
>
> Thanks,
> Jeremy
Re: [DISCUSSION] Aries release
Posted by Alasdair Nottingham <no...@apache.org>.
I agree.
Alasdair
On 26 Jan 2010, at 17:34, Jeremy Hughes <hu...@apache.org> wrote:
> There's been a lot of activity lately so I'd like to propose we do a
> release so we can get some wider user feedback. I think we should give
> it a version of 0.1 and stick to versions <1 while we're in the
> Incubator.
>
> Then there is the question of whether to independently version the
> high level modules or keep them lock-step. For now I think we should
> keep them lock-step until we feel a need to change that.
>
> What does everyone think?
>
> Thanks,
> Jeremy
Re: [DISCUSSION] Aries release
Posted by Donald Woods <dw...@apache.org>.
What about creating a common assembly under samples based on the current
blog-assembly, which would allow users to drop-in the Blog, AriesTrader
or their own wab/eba?
-Donald
On 1/26/10 12:34 PM, Jeremy Hughes wrote:
> There's been a lot of activity lately so I'd like to propose we do a
> release so we can get some wider user feedback. I think we should give
> it a version of 0.1 and stick to versions <1 while we're in the
> Incubator.
>
> Then there is the question of whether to independently version the
> high level modules or keep them lock-step. For now I think we should
> keep them lock-step until we feel a need to change that.
>
> What does everyone think?
>
> Thanks,
> Jeremy
>
Re: [DISCUSSION] Aries release
Posted by David Bosschaert <da...@gmail.com>.
+1 on doing an Aries release.
I have no strong opinion on the version number.
David
2010/1/26 Jeremy Hughes <hu...@apache.org>:
> There's been a lot of activity lately so I'd like to propose we do a
> release so we can get some wider user feedback. I think we should give
> it a version of 0.1 and stick to versions <1 while we're in the
> Incubator.
>
> Then there is the question of whether to independently version the
> high level modules or keep them lock-step. For now I think we should
> keep them lock-step until we feel a need to change that.
>
> What does everyone think?
>
> Thanks,
> Jeremy
>
Re: [DISCUSSION] Aries release
Posted by Mark Nuttall <mn...@apache.org>.
Yes, there's more than enough content for a 0.1 release. +1
2010/1/26 Jeremy Hughes <hu...@apache.org>
> There's been a lot of activity lately so I'd like to propose we do a
> release so we can get some wider user feedback. I think we should give
> it a version of 0.1 and stick to versions <1 while we're in the
> Incubator.
>
> Then there is the question of whether to independently version the
> high level modules or keep them lock-step. For now I think we should
> keep them lock-step until we feel a need to change that.
>
> What does everyone think?
>
> Thanks,
> Jeremy
>
Re: [DISCUSSION] Aries release
Posted by Alasdair Nottingham <no...@apache.org>.
Good point. I think deprecating them and using a attribute on the
package export to indicate that it is likely to change would be a good
idea.
Alasdair
2010/1/26 David Jencks <da...@yahoo.com>:
> I'd love to see a release of aries-blueprint in particular. I wonder if it
> would be a good idea to mark "deprecated" some of the interfaces such as
> NamespaceHandler that aren't yet in a spec and might change but will be used
> by lots of people? On the other hand geronimo-blueprint got released
> without such markings.
>
> thanks
> david jencks
>
> On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
>
>> There's been a lot of activity lately so I'd like to propose we do a
>> release so we can get some wider user feedback. I think we should give
>> it a version of 0.1 and stick to versions <1 while we're in the
>> Incubator.
>>
>> Then there is the question of whether to independently version the
>> high level modules or keep them lock-step. For now I think we should
>> keep them lock-step until we feel a need to change that.
>>
>> What does everyone think?
>>
>> Thanks,
>> Jeremy
>
>
--
Alasdair Nottingham
not@apache.org
Re: [DISCUSSION] Aries release
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
Makes sense to me.
Regards,
Alan
On Jan 26, 2010, at 11:38 PM, Alasdair Nottingham wrote:
> I do not think it would become undeprecated though. I think when the
> OSGi Alliance specify how namespace handlers work we would end up
> with new interfaces in new packages and we would drop support for
> the existing packages.
>
> Alasdair
>
> On 27 Jan 2010, at 04:39, "Alan D. Cabrera" <li...@toolazydogs.com>
> wrote:
>
>> I've never seen a deprecated interface subsequently become
>> undeprecated.
>>
>> Maybe we could mark the version 1.0-RC1?
>>
>> Just an idea.
>>
>>
>> Regards,
>> Alan
>>
>> On Jan 26, 2010, at 9:59 AM, David Jencks wrote:
>>
>>> I'd love to see a release of aries-blueprint in particular. I
>>> wonder if it would be a good idea to mark "deprecated" some of the
>>> interfaces such as NamespaceHandler that aren't yet in a spec and
>>> might change but will be used by lots of people? On the other
>>> hand geronimo-blueprint got released without such markings.
>>>
>>> thanks
>>> david jencks
>>>
>>> On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
>>>
>>>> There's been a lot of activity lately so I'd like to propose we
>>>> do a
>>>> release so we can get some wider user feedback. I think we should
>>>> give
>>>> it a version of 0.1 and stick to versions <1 while we're in the
>>>> Incubator.
>>>>
>>>> Then there is the question of whether to independently version the
>>>> high level modules or keep them lock-step. For now I think we
>>>> should
>>>> keep them lock-step until we feel a need to change that.
>>>>
>>>> What does everyone think?
>>>>
>>>> Thanks,
>>>> Jeremy
>>>
>>
Re: [DISCUSSION] Aries release
Posted by Alasdair Nottingham <no...@apache.org>.
I do not think it would become undeprecated though. I think when the
OSGi Alliance specify how namespace handlers work we would end up with
new interfaces in new packages and we would drop support for the
existing packages.
Alasdair
On 27 Jan 2010, at 04:39, "Alan D. Cabrera" <li...@toolazydogs.com>
wrote:
> I've never seen a deprecated interface subsequently become
> undeprecated.
>
> Maybe we could mark the version 1.0-RC1?
>
> Just an idea.
>
>
> Regards,
> Alan
>
> On Jan 26, 2010, at 9:59 AM, David Jencks wrote:
>
>> I'd love to see a release of aries-blueprint in particular. I
>> wonder if it would be a good idea to mark "deprecated" some of the
>> interfaces such as NamespaceHandler that aren't yet in a spec and
>> might change but will be used by lots of people? On the other hand
>> geronimo-blueprint got released without such markings.
>>
>> thanks
>> david jencks
>>
>> On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
>>
>>> There's been a lot of activity lately so I'd like to propose we do a
>>> release so we can get some wider user feedback. I think we should
>>> give
>>> it a version of 0.1 and stick to versions <1 while we're in the
>>> Incubator.
>>>
>>> Then there is the question of whether to independently version the
>>> high level modules or keep them lock-step. For now I think we should
>>> keep them lock-step until we feel a need to change that.
>>>
>>> What does everyone think?
>>>
>>> Thanks,
>>> Jeremy
>>
>
Re: [DISCUSSION] Aries release
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
I've never seen a deprecated interface subsequently become undeprecated.
Maybe we could mark the version 1.0-RC1?
Just an idea.
Regards,
Alan
On Jan 26, 2010, at 9:59 AM, David Jencks wrote:
> I'd love to see a release of aries-blueprint in particular. I
> wonder if it would be a good idea to mark "deprecated" some of the
> interfaces such as NamespaceHandler that aren't yet in a spec and
> might change but will be used by lots of people? On the other hand
> geronimo-blueprint got released without such markings.
>
> thanks
> david jencks
>
> On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
>
>> There's been a lot of activity lately so I'd like to propose we do a
>> release so we can get some wider user feedback. I think we should
>> give
>> it a version of 0.1 and stick to versions <1 while we're in the
>> Incubator.
>>
>> Then there is the question of whether to independently version the
>> high level modules or keep them lock-step. For now I think we should
>> keep them lock-step until we feel a need to change that.
>>
>> What does everyone think?
>>
>> Thanks,
>> Jeremy
>
Re: [DISCUSSION] Aries release
Posted by David Jencks <da...@yahoo.com>.
I'd love to see a release of aries-blueprint in particular. I wonder
if it would be a good idea to mark "deprecated" some of the interfaces
such as NamespaceHandler that aren't yet in a spec and might change
but will be used by lots of people? On the other hand geronimo-
blueprint got released without such markings.
thanks
david jencks
On Jan 26, 2010, at 9:34 AM, Jeremy Hughes wrote:
> There's been a lot of activity lately so I'd like to propose we do a
> release so we can get some wider user feedback. I think we should give
> it a version of 0.1 and stick to versions <1 while we're in the
> Incubator.
>
> Then there is the question of whether to independently version the
> high level modules or keep them lock-step. For now I think we should
> keep them lock-step until we feel a need to change that.
>
> What does everyone think?
>
> Thanks,
> Jeremy