You are viewing a plain text version of this content. The canonical link for it is here.
Posted to easyant-dev@incubator.apache.org by Jean-Louis Boudart <je...@gmail.com> on 2013/02/27 21:49:44 UTC
Re: A first release process
Release artifacts are available on dist.apache.org \o/
I've just pushed all plugins to repository.easyant.org.
I think last step is now to update the website (in particular download
page) before anouncing publicly the release.
2013/1/28 Jean-Louis Boudart <je...@gmail.com>
> Just tried modifying the version in revision attribute and i have the same
> issue build failed without error even in debug. Let's debug this later.
>
>
> Another solution is to set the version property like this :
> <property name="version" value="${ivy.version}-incubating"/>
>
> It will force the version scheme in all produced files (manifest,
> version.properties and each distribution archives).
>
> I prefer the shorter version easyant-core-0.9-incubating-bin.zip.
>
>
>
>
>
>
> 2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
>
>> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <je...@gmail.com>
>> a écrit :
>>
>> > If this applies to core only, just updating the version attribute in
>> > core/trunk/module.ivy should do the trick without any other changes.
>>
>> I have just tried that, the build fails at startup but without any error,
>> it just look like a System.exit(1) somewhere...
>>
>> So in the module.ivy I would add a -incubating in the revision. So are we
>> cool with that kind of name for the distribution artifact ?
>> easyant-core-0.9-incubating-build-20130128010814-bin.zip
>> For ASF, it is important that there is "incubating" and the version is
>> clear enough. So this is a question mainly for us the PPMC. Should we
>> prefer something shorter, like easyant-core-0.9-incubating-bin.zip, or the
>> longer version.
>> Personally, I don't mind if we choose one over the other.
>> If we prefer the shorter version, is there any property which I could
>> set, or should I just rename the artifact ?
>>
>> > Should we apply this version scheme also on buildtypes/skeletons etc… ?
>>
>> I will make sure the version on the archive of the source will have the
>> "-incubating" suffix. For the version of each plugin, buildtype, skeleton
>> in the module.ivy, I think we can stick with 0.9.
>>
>> Nicolas
>>
>> >
>> >
>> > 2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
>> >
>> >> I had just a little trouble: the version should be 0.9-incubating.
>> >> What is the best way to make easyant core build to produce a distrib
>> with
>> >> that version ?
>> >> If the solution is to just rename the artifact afterwards, I don't
>> mind,
>> >> we can improve that later.
>> >>
>> >> Nicolas
>> >>
>> >> Le 25 janv. 2013 à 16:00, Nicolas Lalevée <ni...@hibnet.org>
>> a
>> >> écrit :
>> >>
>> >>> Le 24 janv. 2013 à 21:23, Jean-Louis Boudart <
>> >> jeanlouis.boudart@gmail.com> a écrit :
>> >>>
>> >>>> Ivy 2.3.0 release is almost ready, artifacts reached maven central
>> repo.
>> >>>> Vote has ended without any veto. I assume official annouce is just a
>> >>>> question of time now.
>> >>>>
>> >>>> Could we start our release process now ? :p
>> >>>
>> >>> Definitively.
>> >>> I'll proceed soon, probably this week-end.
>> >>>
>> >>> Nicolas
>> >>>
>> >>>> Le 28 déc. 2012 22:53, "Nicolas Lalevée" <ni...@hibnet.org>
>> a
>> >>>> écrit :
>> >>>>
>> >>>>>
>> >>>>> Le 28 déc. 2012 à 22:51, Nicolas Lalevée <
>> nicolas.lalevee@hibnet.org>
>> >> a
>> >>>>> écrit :
>> >>>>>
>> >>>>>>
>> >>>>>> Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <
>> >> jeanlouis.boudart@gmail.com>
>> >>>>> a écrit :
>> >>>>>>
>> >>>>>>> I was thinking about it this morning when i saw Maarten's mail.
>> >>>>>>> Are we supposed to make a RC ? or directly a release?
>> >>>>>>> If apache process forces us to make a RC, then we could do the
>> >> release
>> >>>>> with
>> >>>>>>> current code base and then switch to 2.3.0-final.
>> >>>>>>
>> >>>>>> The ASF doesn't enforce anything about the quality of the code we
>> are
>> >>>>> releasing. It is "just" about IP, License, PMC vote (IMPC in our
>> case),
>> >>>>> source distribution and probably also the svn tagging. So we do
>> what we
>> >>>>> want about versioning of releases.
>> >>>>>>
>> >>>>>>> In other case i would be in favor of waiting ivy 2.3.0 final
>> release.
>> >>>>>>
>> >>>>>> So we'll release an EasyAnt 0.9 with Ivy 2.3.
>> >>>>>
>> >>>>> Actually this will be a 0.9-incubating, as per the Incubator rules.
>> >>>>>
>> >>>>> Nicolas
>> >>>>>
>> >>>>>>
>> >>>>>> Nicolas
>> >>>>>>
>> >>>>>>> By the way, does it sound good if I try do a release just after
>> the
>> >>>>> release
>> >>>>>>> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process
>> >> should
>> >>>>>>> start next week.
>> >>>>>>>
>> >>>>>>> Nicolas
>> >>>>>>>
>> >>>>>>> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <
>> >>>>> jeanlouis.boudart@gmail.com> a
>> >>>>>>> écrit :
>> >>>>>>>
>> >>>>>>>> Oki, maybe it's a premature discussion. Let's go as you described
>> >> for
>> >>>>> the
>> >>>>>>>> first release and we will see in future how to enhance the
>> process.
>> >>>>>>>>
>> >>>>>>>> So no objection for me :)
>> >>>>>>>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <
>> >> nicolas.lalevee@hibnet.org>
>> >>>>> a
>> >>>>>>>> écrit :
>> >>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <
>> >>>>> jeanlouis.boudart@gmail.com>
>> >>>>>>>>> a écrit :
>> >>>>>>>>>
>> >>>>>>>>>> Sounds good for me.
>> >>>>>>>>>>
>> >>>>>>>>>> But i'm wondering if it won't be safer to replace the step :
>> >>>>>>>>>> * invoke ant install-all: it will put every plugins into a
>> shared
>> >>>>>>>>>> repository locally on the build machine
>> >>>>>>>>>> by
>> >>>>>>>>>> * invoke ant install-all: it will put every plugins into a
>> staging
>> >>>>>>>>>> repository on repo.easyant.org
>> >>>>>>>>>>
>> >>>>>>>>>> For the first release i agree that it doesn't change anything.
>> >>>>>>>>>
>> >>>>>>>>> The problem with that change is that only people having write
>> >> access
>> >>>>> to
>> >>>>>>>>> repo.easyant.org could then build a distribution of easyant. We
>> >> must
>> >>>>> be
>> >>>>>>>>> sure there is a simple enough process for people to build
>> easyant
>> >> from
>> >>>>>>> the
>> >>>>>>>>> sources.
>> >>>>>>>>>
>> >>>>>>>>>> But for future, plugins could be released individually. To make
>> >> them
>> >>>>>>>>>> accessible (as they will not be in the main distribution)
>> >>>>>>>>>> repo.easyant.orgcould be a good host. Like for the main
>> >> distribution,
>> >>>>>>>>>> we could use a
>> >>>>>>>>>> staging area to make them accessible before being definitivly
>> >>>>> "public"
>> >>>>>>>>> (or
>> >>>>>>>>>> "stable").
>> >>>>>>>>>>
>> >>>>>>>>>> WDYT ?
>> >>>>>>>>>
>> >>>>>>>>> No objection. But we must make the difference between building a
>> >>>>>>>>> distribution and releasing. Building a distribution should be
>> >>>>> possible to
>> >>>>>>>>> anyone having the sources. Making a release should then be
>> >> building a
>> >>>>>>>>> distribution but pushed onto Apache infra for the sources at
>> >> least, or
>> >>>>>>>>> somewhere else as repo.easyant.org for the binaries.
>> >>>>>>>>>
>> >>>>>>>>> Nicolas
>> >>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>> >>>>>>>>>>
>> >>>>>>>>>>> So we have EasyAnt core, the end user executable, and the
>> EasyAnt
>> >>>>>>>>> plugins,
>> >>>>>>>>>>> buildtypes and skeletons (the build.xml pieces) to release.
>> >>>>>>>>>>>
>> >>>>>>>>>>> All core and plugins have a build based on EasyAnt. Since this
>> >> build
>> >>>>>>>>> loop,
>> >>>>>>>>>>> I have setup some very basic build.xml so we can bootstrap a
>> >> first
>> >>>>>>>>> release.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Here is the process I am suggesting:
>> >>>>>>>>>>> - in plugins, buildtypes and skeletons:
>> >>>>>>>>>>> -- do a svn tag.
>> >>>>>>>>>>> -- invoke ant distributions: it will build a
>> >>>>> easyant-xxxx-0.9-src.zip
>> >>>>>>>>>>> package to be publish in the release area
>> >>>>>>>>>>> -- invoke ant install-all: it will put every plugins into a
>> >> shared
>> >>>>>>>>>>> repository locally on the build machine
>> >>>>>>>>>>> - in core:
>> >>>>>>>>>>> -- do a svn tag
>> >>>>>>>>>>> -- invoke ant run -Dtarget=distribution: this is building
>> >> easyant,
>> >>>>> and
>> >>>>>>>>>>> then running easyant with the plugins just installed in the
>> >> shared
>> >>>>>>>>> repo. At
>> >>>>>>>>>>> the end we should have a easyant-core-0.9-bin.zip and a
>> >>>>>>>>>>> easyant-core-0.9-src.zip ready to be published in the release
>> >> area
>> >>>>>>>>>>> - push the *-src.zip and *-bin.zip into the staging release
>> area
>> >>>>>>>>>>> - md5, sha1 and sign the zip files
>> >>>>>>>>>>> - vote for the release
>> >>>>>>>>>>>
>> >>>>>>>>>>> Once the process released finished, the source of this 0.9
>> will
>> >> be
>> >>>>> then
>> >>>>>>>>>>> available via 4 zip files. A zip distribution will be
>> available
>> >> to
>> >>>>>>>>> download
>> >>>>>>>>>>> for end user for immediate use.
>> >>>>>>>>>>> And as an after release process, we would make the plugins,
>> >>>>> buildtypes
>> >>>>>>>>> and
>> >>>>>>>>>>> skeletons available via our repository on repo.easyant.org.
>> >>>>>>>>>>>
>> >>>>>>>>>>> Does it sound good for everyone ?
>> >>>>>>>>>>>
>> >>>>>>>>>>> Nicolas
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>> --
>> >>>>>>>>>> Jean Louis Boudart
>> >>>>>>>>>> Independent consultant
>> >>>>>>>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>
>> >>>>>
>> >>>>>
>> >>>
>> >>
>> >>
>> >
>> >
>> > --
>> > Jean Louis Boudart
>> > Independent consultant
>> > Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>
>>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>
--
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/
Re: A first release process
Posted by Nicolas Lalevée <ni...@hibnet.org>.
Note that we need a proper download page which follows the ASF guidelines.
More to read there:
http://www.apache.org/dev/release-download-pages.html
Nicolas
Le 27 févr. 2013 à 22:49, Jean-Louis Boudart <je...@gmail.com> a écrit :
> Release artifacts are available on dist.apache.org \o/
> I've just pushed all plugins to repository.easyant.org.
>
> I think last step is now to update the website (in particular download
> page) before anouncing publicly the release.
>
>
> 2013/1/28 Jean-Louis Boudart <je...@gmail.com>
>
>> Just tried modifying the version in revision attribute and i have the same
>> issue build failed without error even in debug. Let's debug this later.
>>
>>
>> Another solution is to set the version property like this :
>> <property name="version" value="${ivy.version}-incubating"/>
>>
>> It will force the version scheme in all produced files (manifest,
>> version.properties and each distribution archives).
>>
>> I prefer the shorter version easyant-core-0.9-incubating-bin.zip.
>>
>>
>>
>>
>>
>>
>> 2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
>>
>>> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <je...@gmail.com>
>>> a écrit :
>>>
>>>> If this applies to core only, just updating the version attribute in
>>>> core/trunk/module.ivy should do the trick without any other changes.
>>>
>>> I have just tried that, the build fails at startup but without any error,
>>> it just look like a System.exit(1) somewhere...
>>>
>>> So in the module.ivy I would add a -incubating in the revision. So are we
>>> cool with that kind of name for the distribution artifact ?
>>> easyant-core-0.9-incubating-build-20130128010814-bin.zip
>>> For ASF, it is important that there is "incubating" and the version is
>>> clear enough. So this is a question mainly for us the PPMC. Should we
>>> prefer something shorter, like easyant-core-0.9-incubating-bin.zip, or the
>>> longer version.
>>> Personally, I don't mind if we choose one over the other.
>>> If we prefer the shorter version, is there any property which I could
>>> set, or should I just rename the artifact ?
>>>
>>>> Should we apply this version scheme also on buildtypes/skeletons etc… ?
>>>
>>> I will make sure the version on the archive of the source will have the
>>> "-incubating" suffix. For the version of each plugin, buildtype, skeleton
>>> in the module.ivy, I think we can stick with 0.9.
>>>
>>> Nicolas
>>>
>>>>
>>>>
>>>> 2013/1/28 Nicolas Lalevée <ni...@hibnet.org>
>>>>
>>>>> I had just a little trouble: the version should be 0.9-incubating.
>>>>> What is the best way to make easyant core build to produce a distrib
>>> with
>>>>> that version ?
>>>>> If the solution is to just rename the artifact afterwards, I don't
>>> mind,
>>>>> we can improve that later.
>>>>>
>>>>> Nicolas
>>>>>
>>>>> Le 25 janv. 2013 à 16:00, Nicolas Lalevée <ni...@hibnet.org>
>>> a
>>>>> écrit :
>>>>>
>>>>>> Le 24 janv. 2013 à 21:23, Jean-Louis Boudart <
>>>>> jeanlouis.boudart@gmail.com> a écrit :
>>>>>>
>>>>>>> Ivy 2.3.0 release is almost ready, artifacts reached maven central
>>> repo.
>>>>>>> Vote has ended without any veto. I assume official annouce is just a
>>>>>>> question of time now.
>>>>>>>
>>>>>>> Could we start our release process now ? :p
>>>>>>
>>>>>> Definitively.
>>>>>> I'll proceed soon, probably this week-end.
>>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>>> Le 28 déc. 2012 22:53, "Nicolas Lalevée" <ni...@hibnet.org>
>>> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>>
>>>>>>>> Le 28 déc. 2012 à 22:51, Nicolas Lalevée <
>>> nicolas.lalevee@hibnet.org>
>>>>> a
>>>>>>>> écrit :
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 28 déc. 2012 à 22:05, Jean-Louis Boudart <
>>>>> jeanlouis.boudart@gmail.com>
>>>>>>>> a écrit :
>>>>>>>>>
>>>>>>>>>> I was thinking about it this morning when i saw Maarten's mail.
>>>>>>>>>> Are we supposed to make a RC ? or directly a release?
>>>>>>>>>> If apache process forces us to make a RC, then we could do the
>>>>> release
>>>>>>>> with
>>>>>>>>>> current code base and then switch to 2.3.0-final.
>>>>>>>>>
>>>>>>>>> The ASF doesn't enforce anything about the quality of the code we
>>> are
>>>>>>>> releasing. It is "just" about IP, License, PMC vote (IMPC in our
>>> case),
>>>>>>>> source distribution and probably also the svn tagging. So we do
>>> what we
>>>>>>>> want about versioning of releases.
>>>>>>>>>
>>>>>>>>>> In other case i would be in favor of waiting ivy 2.3.0 final
>>> release.
>>>>>>>>>
>>>>>>>>> So we'll release an EasyAnt 0.9 with Ivy 2.3.
>>>>>>>>
>>>>>>>> Actually this will be a 0.9-incubating, as per the Incubator rules.
>>>>>>>>
>>>>>>>> Nicolas
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Nicolas
>>>>>>>>>
>>>>>>>>>> By the way, does it sound good if I try do a release just after
>>> the
>>>>>>>> release
>>>>>>>>>> of Ivy 2.3.0 (so we can use it in EasyAnt) ? Ivy release process
>>>>> should
>>>>>>>>>> start next week.
>>>>>>>>>>
>>>>>>>>>> Nicolas
>>>>>>>>>>
>>>>>>>>>> Le 28 déc. 2012 à 20:14, Jean-Louis Boudart <
>>>>>>>> jeanlouis.boudart@gmail.com> a
>>>>>>>>>> écrit :
>>>>>>>>>>
>>>>>>>>>>> Oki, maybe it's a premature discussion. Let's go as you described
>>>>> for
>>>>>>>> the
>>>>>>>>>>> first release and we will see in future how to enhance the
>>> process.
>>>>>>>>>>>
>>>>>>>>>>> So no objection for me :)
>>>>>>>>>>> Le 28 déc. 2012 19:19, "Nicolas Lalevée" <
>>>>> nicolas.lalevee@hibnet.org>
>>>>>>>> a
>>>>>>>>>>> écrit :
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Le 28 déc. 2012 à 17:42, Jean-Louis Boudart <
>>>>>>>> jeanlouis.boudart@gmail.com>
>>>>>>>>>>>> a écrit :
>>>>>>>>>>>>
>>>>>>>>>>>>> Sounds good for me.
>>>>>>>>>>>>>
>>>>>>>>>>>>> But i'm wondering if it won't be safer to replace the step :
>>>>>>>>>>>>> * invoke ant install-all: it will put every plugins into a
>>> shared
>>>>>>>>>>>>> repository locally on the build machine
>>>>>>>>>>>>> by
>>>>>>>>>>>>> * invoke ant install-all: it will put every plugins into a
>>> staging
>>>>>>>>>>>>> repository on repo.easyant.org
>>>>>>>>>>>>>
>>>>>>>>>>>>> For the first release i agree that it doesn't change anything.
>>>>>>>>>>>>
>>>>>>>>>>>> The problem with that change is that only people having write
>>>>> access
>>>>>>>> to
>>>>>>>>>>>> repo.easyant.org could then build a distribution of easyant. We
>>>>> must
>>>>>>>> be
>>>>>>>>>>>> sure there is a simple enough process for people to build
>>> easyant
>>>>> from
>>>>>>>>>> the
>>>>>>>>>>>> sources.
>>>>>>>>>>>>
>>>>>>>>>>>>> But for future, plugins could be released individually. To make
>>>>> them
>>>>>>>>>>>>> accessible (as they will not be in the main distribution)
>>>>>>>>>>>>> repo.easyant.orgcould be a good host. Like for the main
>>>>> distribution,
>>>>>>>>>>>>> we could use a
>>>>>>>>>>>>> staging area to make them accessible before being definitivly
>>>>>>>> "public"
>>>>>>>>>>>> (or
>>>>>>>>>>>>> "stable").
>>>>>>>>>>>>>
>>>>>>>>>>>>> WDYT ?
>>>>>>>>>>>>
>>>>>>>>>>>> No objection. But we must make the difference between building a
>>>>>>>>>>>> distribution and releasing. Building a distribution should be
>>>>>>>> possible to
>>>>>>>>>>>> anyone having the sources. Making a release should then be
>>>>> building a
>>>>>>>>>>>> distribution but pushed onto Apache infra for the sources at
>>>>> least, or
>>>>>>>>>>>> somewhere else as repo.easyant.org for the binaries.
>>>>>>>>>>>>
>>>>>>>>>>>> Nicolas
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2012/12/28 Nicolas Lalevée <ni...@hibnet.org>
>>>>>>>>>>>>>
>>>>>>>>>>>>>> So we have EasyAnt core, the end user executable, and the
>>> EasyAnt
>>>>>>>>>>>> plugins,
>>>>>>>>>>>>>> buildtypes and skeletons (the build.xml pieces) to release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> All core and plugins have a build based on EasyAnt. Since this
>>>>> build
>>>>>>>>>>>> loop,
>>>>>>>>>>>>>> I have setup some very basic build.xml so we can bootstrap a
>>>>> first
>>>>>>>>>>>> release.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here is the process I am suggesting:
>>>>>>>>>>>>>> - in plugins, buildtypes and skeletons:
>>>>>>>>>>>>>> -- do a svn tag.
>>>>>>>>>>>>>> -- invoke ant distributions: it will build a
>>>>>>>> easyant-xxxx-0.9-src.zip
>>>>>>>>>>>>>> package to be publish in the release area
>>>>>>>>>>>>>> -- invoke ant install-all: it will put every plugins into a
>>>>> shared
>>>>>>>>>>>>>> repository locally on the build machine
>>>>>>>>>>>>>> - in core:
>>>>>>>>>>>>>> -- do a svn tag
>>>>>>>>>>>>>> -- invoke ant run -Dtarget=distribution: this is building
>>>>> easyant,
>>>>>>>> and
>>>>>>>>>>>>>> then running easyant with the plugins just installed in the
>>>>> shared
>>>>>>>>>>>> repo. At
>>>>>>>>>>>>>> the end we should have a easyant-core-0.9-bin.zip and a
>>>>>>>>>>>>>> easyant-core-0.9-src.zip ready to be published in the release
>>>>> area
>>>>>>>>>>>>>> - push the *-src.zip and *-bin.zip into the staging release
>>> area
>>>>>>>>>>>>>> - md5, sha1 and sign the zip files
>>>>>>>>>>>>>> - vote for the release
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Once the process released finished, the source of this 0.9
>>> will
>>>>> be
>>>>>>>> then
>>>>>>>>>>>>>> available via 4 zip files. A zip distribution will be
>>> available
>>>>> to
>>>>>>>>>>>> download
>>>>>>>>>>>>>> for end user for immediate use.
>>>>>>>>>>>>>> And as an after release process, we would make the plugins,
>>>>>>>> buildtypes
>>>>>>>>>>>> and
>>>>>>>>>>>>>> skeletons available via our repository on repo.easyant.org.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does it sound good for everyone ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Nicolas
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Jean Louis Boudart
>>>>>>>>>>>>> Independent consultant
>>>>>>>>>>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Jean Louis Boudart
>>>> Independent consultant
>>>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>>
>>>
>>
>>
>> --
>> Jean Louis Boudart
>> Independent consultant
>> Apache EasyAnt commiter http://incubator.apache.org/easyant/
>>
>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/