I have asked the infra to close the mailing lists:
https://issues.apache.org/jira/browse/INFRA-6049

If possible you will be automatically subscribed to the merged mailing list.

Nicolas

I have started to move stuff. The svn tree is moved into Ant's subtree. It is now there:
http://svn.apache.org/repos/asf/ant/easyant/
And the site is now there:
http://svn.apache.org/repos/asf/ant/site/easyant/
But don't touch to the site for now, I am waiting for the infra to change the svnpubsub: https://issues.apache.org/jira/browse/INFRA-6048

I have not tested myself, but the following command line will change the location in your
working copy for the source code:
svn switch --relocate http://svn.apache.org/repos/asf/incubator/easyant http://svn.apache.org/repos/asf/ant/easyant/

Nicolas

Hi,

thank you. 

I was just wondering whether there is some hidden semantics for the dependencies/artifacts
contained in the active build configurations - something in the way of:
A plugin for compiling Java determines the classpath by running a resolve on the Ivy file
_with the active build configurations_. So when I switch configurations with "-C", dependencies
will switch as well. But obviously there is not (and it would probably be dangerous to implement
something like that anyway). Its just a bit misleading then to use the same configurations
in the example for different build profiles as well as for different sets of dependencies.

By the way, there seems to be a bug in the way that properties are handled in different build
configurations. The interface EasyAntModuleDescriptor grants access on properties in a map
whose key is the property name:

    /**
     * Get all the properties loaded inside the <easyant> tag.
     * 
     * @return a map of properties
     */
    Map<String, PropertyDescriptor> getProperties();

So there can only be one PropertyDescriptor for each given property. (And a single PropertyDescriptor
can also only hold one value.) If you now specify two <ea:property> elements for different
build configurations with different values, like in the example in [1], only the last one
will be stored. (So in the example it will be actually only be present for configuration "linux"
with value "foobar" and not set for configuration "windows" at all.)

<ea:property name="foo" value="bar" conf="windows"/>
<ea:property name="foo" value="foobar" conf="linux"/>

You should replace the map with a list or add a parameter to pass in active configurations.
I didn't have time yet to look if this issue is already filed/file it myself.

Best regards,
Tim Enderling

[1] http://incubator.apache.org/easyant/history/trunk/howto/BuildConfigurations.html.

> -----Original Message-----
> From: Jean-Louis Boudart [mailto:jeanlouis.boudart@gmail.com]
> Sent: Donnerstag, 21. März 2013 21:22
> To: easyant-dev@incubator.apache.org
> Subject: Re: Build configurations
> 
> EasyAntMagicNames.ACTIVE_
> BUILD_CONFIGURATIONS is currently setted in
> EasyAntEngine.initProject(Project project) method.
> 
> If you're running easyant through command it will be setted with "-C"
> switch
> > easyant -C yourbuildConfiguration
> 
> This property is then read by LoadModule task.
> 
> The feature works pretty well, but i agree that there are some misspelled
> method, variables in easyant-core code itself on this topic.
> 
> 
> 2013/3/21 Jean-Louis Boudart <jeanlouis.boudart@gmail.com>
> 
> > Hi,
> > Easyant is build on top of ivy. Our entry point is a module descriptor (a
> > pure ivy file) where you will describe:
> >  * standard ivy informations such as project name / version /
> dependencies
> >  * informations introduced by easyant like :
> >     - properties
> >     - plugins
> >
> >
> > You can associate the following things with a particular build
> > configuration:
> >
> >    1. Property values
> >    2. Plugins
> >    3. Dependencies, artifacts (de facto as we uses ivy :))
> >
> > We wanted to make build configuration aware of both ivy
> > (dependencies,artifacts) and easyant stuff. So we chose to plug our
> > mechanism into an existing ivy feature instead of introducing a new
> concept.
> >

-- snip --

EasyAntMagicNames.ACTIVE_
BUILD_CONFIGURATIONS is currently setted in
EasyAntEngine.initProject(Project project) method.

If you're running easyant through command it will be setted with "-C" switch
> easyant -C yourbuildConfiguration

This property is then read by LoadModule task.

The feature works pretty well, but i agree that there are some misspelled
method, variables in easyant-core code itself on this topic.


2013/3/21 Jean-Louis Boudart <jeanlouis.boudart@gmail.com>

> Hi,
> Easyant is build on top of ivy. Our entry point is a module descriptor (a
> pure ivy file) where you will describe:
>  * standard ivy informations such as project name / version / dependencies
>  * informations introduced by easyant like :
>     - properties
>     - plugins
>
>
> You can associate the following things with a particular build
> configuration:
>
>    1. Property values
>    2. Plugins
>    3. Dependencies, artifacts (de facto as we uses ivy :))
>
> We wanted to make build configuration aware of both ivy
> (dependencies,artifacts) and easyant stuff. So we chose to plug our
> mechanism into an existing ivy feature instead of introducing a new concept.
>
>
>
>
>
> 2013/3/21 Jean-Louis Boudart <jeanlouis.boudart@gmail.com>
>
>> Hi,
>> Easyant is build on top of ivy. Our entry point is a module descriptor (a
>> pure ivy file) where you will describe:
>>  * standard ivy informations such as project name / version / dependencies
>>  * informations introduced by easyant like :
>>  properties
>>  *
>>
>> You can associate the following things with a particular build
>> configuration:
>>
>>    1. Property values
>>    2. Plugins
>>    3. Dependencies (de facto as we uses ivy :))
>>
>>
>> Hi,
>>
>> I was wondering: What's the idea behind reusing Ivy configurations for
>> different build profiles?
>>
>> I've read [1], and I understand the general notion of loading different
>> sets of plugins/properties for different use cases. I however don't see any
>> direct connection between how Ivy uses configurations (to specify different
>> sets of artifacts and dependencies) with your usage. (The property
>> EasyAntMagicNames.ACTIVE_BUILD_CONFIGURATIONS does not seem to be read
>> anywhere?!)
>>
>> So the question is - why do your build profiles need to be Ivy
>> configurations?
>>
>> Best regards,
>>
>> [1]
>> http://incubator.apache.org/easyant/history/trunk/howto/BuildConfigurations.html
>> .
>>
>>
>
>
> --
> 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/

Hi,
Easyant is build on top of ivy. Our entry point is a module descriptor (a
pure ivy file) where you will describe:
 * standard ivy informations such as project name / version / dependencies
 * informations introduced by easyant like :
    - properties
    - plugins


You can associate the following things with a particular build
configuration:

   1. Property values
   2. Plugins
   3. Dependencies, artifacts (de facto as we uses ivy :))

We wanted to make build configuration aware of both ivy
(dependencies,artifacts) and easyant stuff. So we chose to plug our
mechanism into an existing ivy feature instead of introducing a new concept.





2013/3/21 Jean-Louis Boudart <jeanlouis.boudart@gmail.com>

> Hi,
> Easyant is build on top of ivy. Our entry point is a module descriptor (a
> pure ivy file) where you will describe:
>  * standard ivy informations such as project name / version / dependencies
>  * informations introduced by easyant like :
>  properties
>  *
>
> You can associate the following things with a particular build
> configuration:
>
>    1. Property values
>    2. Plugins
>    3. Dependencies (de facto as we uses ivy :))
>
>
> Hi,
>
> I was wondering: What's the idea behind reusing Ivy configurations for
> different build profiles?
>
> I've read [1], and I understand the general notion of loading different
> sets of plugins/properties for different use cases. I however don't see any
> direct connection between how Ivy uses configurations (to specify different
> sets of artifacts and dependencies) with your usage. (The property
> EasyAntMagicNames.ACTIVE_BUILD_CONFIGURATIONS does not seem to be read
> anywhere?!)
>
> So the question is - why do your build profiles need to be Ivy
> configurations?
>
> Best regards,
>
> [1]
> http://incubator.apache.org/easyant/history/trunk/howto/BuildConfigurations.html
> .
>
>


-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/

Hi,
Easyant is build on top of ivy. Our entry point is a module descriptor (a
pure ivy file) where you will describe:
 * standard ivy informations such as project name / version / dependencies
 * informations introduced by easyant like :
 properties
 *

You can associate the following things with a particular build
configuration:

   1. Property values
   2. Plugins
   3. Dependencies (de facto as we uses ivy :))


Hi,

I was wondering: What's the idea behind reusing Ivy configurations for
different build profiles?

I've read [1], and I understand the general notion of loading different
sets of plugins/properties for different use cases. I however don't see any
direct connection between how Ivy uses configurations (to specify different
sets of artifacts and dependencies) with your usage. (The property
EasyAntMagicNames.ACTIVE_BUILD_CONFIGURATIONS does not seem to be read
anywhere?!)

So the question is - why do your build profiles need to be Ivy
configurations?

Best regards,

[1]
http://incubator.apache.org/easyant/history/trunk/howto/BuildConfigurations.html
.

Hi,

I was wondering: What's the idea behind reusing Ivy configurations for different build profiles?


I've read [1], and I understand the general notion of loading different sets of plugins/properties
for different use cases. I however don't see any direct connection between how Ivy uses configurations
(to specify different sets of artifacts and dependencies) with your usage. (The property EasyAntMagicNames.ACTIVE_BUILD_CONFIGURATIONS
does not seem to be read anywhere?!)

So the question is - why do your build profiles need to be Ivy configurations? 

Best regards,

[1] http://incubator.apache.org/easyant/history/trunk/howto/BuildConfigurations.html.

Le 16 mars 2013 à 01:25, Nicolas Lalevée <nicolas.lalevee@hibnet.org> a écrit :

> Hi guys,
> 
> The IPMC has just accepted the proposition to promote EasyAnt as a subproject of Ant.
[1]
> 
> Congrats !
> 
> And thank you mentors to have stayed with us and kept a look on us on this slow and long
graduation.
> 
> The work is still not finished though, we need to clean the place.
> To be read: http://incubator.apache.org/guides/graduation.html
> 
> About moving the resources (svn, website, mailing lists, jira), I'll start a thread on
dev@ant.apache.org. Note that is easyant-dev@ will probably closing in favor of ant-dev, so
I encourage everybody here to subscribe to dev@ant.apache.org if you want to be kept in the
loop (or list members can all be subscribed there by the infra ?).
> 
> About the incubator itself, we need to update its graduated status there:
> http://incubator.apache.org/projects/easyant.html
> http://incubator.apache.org/projects/index.html
> http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings.xml

I have updated the sources.
I am not familiar with the publishing process, if anyone has time, he's welcomed to proceed.

Nicolas

Hi guys,

The IPMC has just accepted the proposition to promote EasyAnt as a subproject of Ant. [1]

Congrats !

And thank you mentors to have stayed with us and kept a look on us on this slow and long graduation.

The work is still not finished though, we need to clean the place.
To be read: http://incubator.apache.org/guides/graduation.html

About moving the resources (svn, website, mailing lists, jira), I'll start a thread on dev@ant.apache.org.
Note that is easyant-dev@ will probably closing in favor of ant-dev, so I encourage everybody
here to subscribe to dev@ant.apache.org if you want to be kept in the loop (or list members
can all be subscribed there by the infra ?).

About the incubator itself, we need to update its graduated status there:
http://incubator.apache.org/projects/easyant.html
http://incubator.apache.org/projects/index.html
http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings.xml

And I guess that's it ?

Nicolas

[1] http://mail-archives.apache.org/mod_mbox/incubator-general/201303.mbox/%3CF5DF2FAD-AE13-4077-B7DB-7509783C66EC%40hibnet.org%3E

On 2013-03-06, Nicolas Lalevée wrote:

> So my guess now is that we need a formal vote on incubator-general@
> about leaving the incubator and going under the Ant PMC umbrella. And
> then clean up the resources used at the incubator and move them into
> Ant's space.

<http://incubator.apache.org/guides/graduation.html#subproject>
"graduation approval vote".  So yes, you are correct.

Stefan

I don't know yet enough how it works. Others projects are supposed to vote
again on general at i.a.o. Not sure it make sense for non TLP.

We should probably ask this on general at incubator with a link on vote
result.
Le 6 mars 2013 20:37, "Nicolas Lalevée" <nicolas.lalevee@hibnet.org> a
écrit :

> We have just been accepted to be a subproject of Ant, just like Ivy
> already is.
>
> So my guess now is that we need a formal vote on incubator-general@ about
> leaving the incubator and going under the Ant PMC umbrella. And then clean
> up the resources used at the incubator and move them into Ant's space.
>
> Is that it ?
>
> Nicolas
>
>

We have just been accepted to be a subproject of Ant, just like Ivy already is.

So my guess now is that we need a formal vote on incubator-general@ about leaving the incubator
and going under the Ant PMC umbrella. And then clean up the resources used at the incubator
and move them into Ant's space.

Is that it ?

Nicolas

Thanks for your feedback, i've updated it with your recommandations.


2013/3/6 Dridi Boukelmoune <dridi.boukelmoune@zenika.com>

> My feedback:
>
> It's a nice introduction which goes through the essentials of a
> "getting started" tutorial. However I would change little things:
>
> - In the end of the skeleton part, you should probably mention that
> the organisation/module/revision terminology comes from Ivy (it does,
> right ?)
>
> - instead of “targets/artifacts” => target without the trailing "s" ?
>
> - In the module.ant part, you should probably say that it will too be
> explained in a future article
>
> - In the end, the "Module files documentation" link is missing its
> href attribute
>
> Best Regards,
> Dridi
>
> On Wed, Mar 6, 2013 at 8:37 AM, Jean-Louis Boudart
> <jeanlouis.boudart@gmail.com> wrote:
> > Here is the first one
> http://blog.easyant.org/getting-started-with-easyant/
> > Le 21 févr. 2013 10:31, "Jean-Louis Boudart" <
> jeanlouis.boudart@gmail.com>
> > a écrit :
> >
> > You're feedback will be really appreciated :)
> >
> > I'll publish the first article just after the release announce.
> >
> >
> > 2013/2/19 Dridi Boukelmoune <dridi.boukelmoune@zenika.com>
> >
> >> Hi,
> >>
> >> As a very begginer I would be glad to review the articles.
> >>
> >> Best Regards,
> >> Dridi
> >>
> >> On Mon, Feb 18, 2013 at 9:22 PM, Jean-Louis Boudart
> >> <jeanlouis.boudart@gmail.com> wrote:
> >> > Hi there,
> >> >
> >> > I'm currently writing a set of tutorial on our blog. The idea is to
> >> start a
> >> > simple webapp project, adapt it with project specific targets , and
> >> > factorize the code in a reusable plugin.
> >> > * a getting started : for begginers
> >> > * adapting project to your needs  : to show how we can configure
> easyant
> >> > including custom targets and how we can plug into the project
> lifecycle.
> >> > Here i suggest to implement a missing feature code coverage for
> example.
> >> > * writting plugin : extract coverage stuff into a reusable plugin
> >> >
> >> > Why not doing this on our documentation ?
> >> >    - to make promotion of easyant
> >> >    - to let people comment specific topic and see missing points in
> our
> >> > tutorials
> >> >
> >> > Once we'll get enough feedback we could then merge those tutorials in
> our
> >> > official documentation.
> >> >
> >> > Are there volunteers to review those article ? :p
> >> >
> >> > Cheers,
> >> > Jean-Louis Boudart
> >>
> >
> >
> >
> > --
> > 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/

My feedback:

It's a nice introduction which goes through the essentials of a
"getting started" tutorial. However I would change little things:

- In the end of the skeleton part, you should probably mention that
the organisation/module/revision terminology comes from Ivy (it does,
right ?)

- instead of “targets/artifacts” => target without the trailing "s" ?

- In the module.ant part, you should probably say that it will too be
explained in a future article

- In the end, the "Module files documentation" link is missing its
href attribute

Best Regards,
Dridi

On Wed, Mar 6, 2013 at 8:37 AM, Jean-Louis Boudart
<jeanlouis.boudart@gmail.com> wrote:
> Here is the first one http://blog.easyant.org/getting-started-with-easyant/
> Le 21 févr. 2013 10:31, "Jean-Louis Boudart" <jeanlouis.boudart@gmail.com>
> a écrit :
>
> You're feedback will be really appreciated :)
>
> I'll publish the first article just after the release announce.
>
>
> 2013/2/19 Dridi Boukelmoune <dridi.boukelmoune@zenika.com>
>
>> Hi,
>>
>> As a very begginer I would be glad to review the articles.
>>
>> Best Regards,
>> Dridi
>>
>> On Mon, Feb 18, 2013 at 9:22 PM, Jean-Louis Boudart
>> <jeanlouis.boudart@gmail.com> wrote:
>> > Hi there,
>> >
>> > I'm currently writing a set of tutorial on our blog. The idea is to
>> start a
>> > simple webapp project, adapt it with project specific targets , and
>> > factorize the code in a reusable plugin.
>> > * a getting started : for begginers
>> > * adapting project to your needs  : to show how we can configure easyant
>> > including custom targets and how we can plug into the project lifecycle.
>> > Here i suggest to implement a missing feature code coverage for example.
>> > * writting plugin : extract coverage stuff into a reusable plugin
>> >
>> > Why not doing this on our documentation ?
>> >    - to make promotion of easyant
>> >    - to let people comment specific topic and see missing points in our
>> > tutorials
>> >
>> > Once we'll get enough feedback we could then merge those tutorials in our
>> > official documentation.
>> >
>> > Are there volunteers to review those article ? :p
>> >
>> > Cheers,
>> > Jean-Louis Boudart
>>
>
>
>
> --
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/

Here is the first one http://blog.easyant.org/getting-started-with-easyant/
Le 21 févr. 2013 10:31, "Jean-Louis Boudart" <jeanlouis.boudart@gmail.com>
a écrit :

You're feedback will be really appreciated :)

I'll publish the first article just after the release announce.


2013/2/19 Dridi Boukelmoune <dridi.boukelmoune@zenika.com>

> Hi,
>
> As a very begginer I would be glad to review the articles.
>
> Best Regards,
> Dridi
>
> On Mon, Feb 18, 2013 at 9:22 PM, Jean-Louis Boudart
> <jeanlouis.boudart@gmail.com> wrote:
> > Hi there,
> >
> > I'm currently writing a set of tutorial on our blog. The idea is to
> start a
> > simple webapp project, adapt it with project specific targets , and
> > factorize the code in a reusable plugin.
> > * a getting started : for begginers
> > * adapting project to your needs  : to show how we can configure easyant
> > including custom targets and how we can plug into the project lifecycle.
> > Here i suggest to implement a missing feature code coverage for example.
> > * writting plugin : extract coverage stuff into a reusable plugin
> >
> > Why not doing this on our documentation ?
> >    - to make promotion of easyant
> >    - to let people comment specific topic and see missing points in our
> > tutorials
> >
> > Once we'll get enough feedback we could then merge those tutorials in our
> > official documentation.
> >
> > Are there volunteers to review those article ? :p
> >
> > Cheers,
> > Jean-Louis Boudart
>



-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/

The Apache EasyAnt project is pleased to announce its 0.9-incubating
release.

Apache Easyant is a toolbox focusing on easing project build processes.
It's based on Apache Ant and Apache Ivy, and allows for maximum flexibily,
improved integration in existing build systems and provides conventions and
guidelines.

Our goals are :

   - to leverage popularity and flexibility of Ant.
   - to integrate Apache Ivy, such that the build system combines a
   ready-to-use dependency manager.
   - to simplify standard build types, such as building web applications,
   JARs etc, by providing ready to use builds.
   - to provide conventions and guidelines.
   - to make plugging-in of fresh functionalities as easy as writing Ant
   scripts.

To still remain adaptable,

   - Though EasyAnt comes with a lot of conventions, we never lock you in.
   - EasyAnt allows you to easily extend existing modules or create and use
   your own modules.
   - EasyAnt makes migration from Ant very simple. Your legacy Ant scripts
   could still be leveraged using EasyAnt.

Key features of this 0.9-incubating release are :

   - dynamic project lifecycle to remain even more flexible (get rid of
   phases in favor of extension point)
   - enhanced multimodule support
   - enhanced exception handling
   - support for offline mode
   - new command line switches and related api to list and describe
   targets, properties, extensionPoints and even parameters (path, filesets)
   - plugin dependencies can be overridden in module descriptors
   - a set of new ant tasks to make plugin writer life easier
   - a lighter distribution with only core plugins/buildtypes
   - online repository for others plugins/buildtypes/skeletons
   - upgrade to Apache Ant 1.8.4 and Apache Ivy 2.3.0
   - numerous bug fixes as documented in Jira and in the release notes

This is the first EasyAnt release under Apache Software Foundation.

You can download this 0.9-incubating release at:
http://incubator.apache.org/easyant/download.cgi

Issues should be reported to:
https://issues.apache.org/jira/browse/EASYANT

More information can be found on the website:
http://incubator.apache.org/easyant/

Regards,
-- 
Jean Louis Boudart

great job !

Nicolas

Le 2 mars 2013 à 00:46, Jean-Louis Boudart <jeanlouis.boudart@gmail.com> a écrit :

> Issue seems to came from how xooki.dir is located :
> [generate] script file ./xooki/xooki.js is not found
> [generate] Result: 11
> 
> An issue with basedir ? A bug in xooki plugin ?
> 
> I found a workarroud (copy xooki in current directory and set basedir
> property to `pwd`). I succeed to generate the website.
> 
> Everything is online ;)
> 
> 
> 2013/3/1 Jean-Louis Boudart <jeanlouis.boudart@gmail.com>
> 
>> I've udpated the download page, but i'm getting errors while generating.
>> Could you try on your side ?
>> Le 27 févr. 2013 23:06, "Nicolas Lalevée" <nicolas.lalevee@hibnet.org> a
>> écrit :
>> 
>> 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 <jeanlouis.boudart@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 <jeanlouis.boudart@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 <nicolas.lalevee@hibnet.org>
>>>>> 
>>>>>> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <
>>> jeanlouis.boudart@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 <nicolas.lalevee@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 <
>>> nicolas.lalevee@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" <
>>> nicolas.lalevee@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
<nicolas.lalevee@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/
>>> 
>>> 
> 
> 
> -- 
> Jean Louis Boudart
> Independent consultant
> Apache EasyAnt commiter http://incubator.apache.org/easyant/

Issue seems to came from how xooki.dir is located :
 [generate] script file ./xooki/xooki.js is not found
 [generate] Result: 11

An issue with basedir ? A bug in xooki plugin ?

I found a workarroud (copy xooki in current directory and set basedir
property to `pwd`). I succeed to generate the website.

Everything is online ;)


2013/3/1 Jean-Louis Boudart <jeanlouis.boudart@gmail.com>

> I've udpated the download page, but i'm getting errors while generating.
> Could you try on your side ?
>  Le 27 févr. 2013 23:06, "Nicolas Lalevée" <nicolas.lalevee@hibnet.org> a
> écrit :
>
> 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 <jeanlouis.boudart@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 <jeanlouis.boudart@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 <nicolas.lalevee@hibnet.org>
>> >>
>> >>> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <
>> jeanlouis.boudart@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 <nicolas.lalevee@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 <
>> nicolas.lalevee@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" <
>> nicolas.lalevee@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
<nicolas.lalevee@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/
>>
>>


-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/

I've udpated the download page, but i'm getting errors while generating.
Could you try on your side ?
 Le 27 févr. 2013 23:06, "Nicolas Lalevée" <nicolas.lalevee@hibnet.org> a
écrit :

> 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 <jeanlouis.boudart@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 <jeanlouis.boudart@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 <nicolas.lalevee@hibnet.org>
> >>
> >>> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <
> jeanlouis.boudart@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 <nicolas.lalevee@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 <
> nicolas.lalevee@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" <
> nicolas.lalevee@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 <nicolas.lalevee@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/
>
>

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 <jeanlouis.boudart@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 <jeanlouis.boudart@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 <nicolas.lalevee@hibnet.org>
>> 
>>> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <jeanlouis.boudart@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 <nicolas.lalevee@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 <nicolas.lalevee@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" <nicolas.lalevee@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 <nicolas.lalevee@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/

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 <jeanlouis.boudart@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 <nicolas.lalevee@hibnet.org>
>
>> Le 28 janv. 2013 à 10:16, Jean-Louis Boudart <jeanlouis.boudart@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 <nicolas.lalevee@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 <nicolas.lalevee@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" <nicolas.lalevee@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 <nicolas.lalevee@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/

done.
http://www.apache.org/dist/incubator/easyant

Nicolas

Le 24 févr. 2013 à 21:13, Nicolas Lalevée <nicolas.lalevee@hibnet.org> a écrit :

> FYI, I am waiting for this:
> 
> https://issues.apache.org/jira/browse/INFRA-5902
> 
> Nicolas
> 

FYI, I am waiting for this:

https://issues.apache.org/jira/browse/INFRA-5902

Nicolas

You're feedback will be really appreciated :)

I'll publish the first article just after the release announce.


2013/2/19 Dridi Boukelmoune <dridi.boukelmoune@zenika.com>

> Hi,
>
> As a very begginer I would be glad to review the articles.
>
> Best Regards,
> Dridi
>
> On Mon, Feb 18, 2013 at 9:22 PM, Jean-Louis Boudart
> <jeanlouis.boudart@gmail.com> wrote:
> > Hi there,
> >
> > I'm currently writing a set of tutorial on our blog. The idea is to
> start a
> > simple webapp project, adapt it with project specific targets , and
> > factorize the code in a reusable plugin.
> > * a getting started : for begginers
> > * adapting project to your needs  : to show how we can configure easyant
> > including custom targets and how we can plug into the project lifecycle.
> > Here i suggest to implement a missing feature code coverage for example.
> > * writting plugin : extract coverage stuff into a reusable plugin
> >
> > Why not doing this on our documentation ?
> >    - to make promotion of easyant
> >    - to let people comment specific topic and see missing points in our
> > tutorials
> >
> > Once we'll get enough feedback we could then merge those tutorials in our
> > official documentation.
> >
> > Are there volunteers to review those article ? :p
> >
> > Cheers,
> > Jean-Louis Boudart
>



-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://incubator.apache.org/easyant/

Hi,

As a very begginer I would be glad to review the articles.

Best Regards,
Dridi

On Mon, Feb 18, 2013 at 9:22 PM, Jean-Louis Boudart
<jeanlouis.boudart@gmail.com> wrote:
> Hi there,
>
> I'm currently writing a set of tutorial on our blog. The idea is to start a
> simple webapp project, adapt it with project specific targets , and
> factorize the code in a reusable plugin.
> * a getting started : for begginers
> * adapting project to your needs  : to show how we can configure easyant
> including custom targets and how we can plug into the project lifecycle.
> Here i suggest to implement a missing feature code coverage for example.
> * writting plugin : extract coverage stuff into a reusable plugin
>
> Why not doing this on our documentation ?
>    - to make promotion of easyant
>    - to let people comment specific topic and see missing points in our
> tutorials
>
> Once we'll get enough feedback we could then merge those tutorials in our
> official documentation.
>
> Are there volunteers to review those article ? :p
>
> Cheers,
> Jean-Louis Boudart

Hi there,

I'm currently writing a set of tutorial on our blog. The idea is to start a
simple webapp project, adapt it with project specific targets , and
factorize the code in a reusable plugin.
* a getting started : for begginers
* adapting project to your needs  : to show how we can configure easyant
including custom targets and how we can plug into the project lifecycle.
Here i suggest to implement a missing feature code coverage for example.
* writting plugin : extract coverage stuff into a reusable plugin

Why not doing this on our documentation ?
   - to make promotion of easyant
   - to let people comment specific topic and see missing points in our
tutorials

Once we'll get enough feedback we could then merge those tutorials in our
official documentation.

Are there volunteers to review those article ? :p

Cheers,
Jean-Louis Boudart

Le 14 févr. 2013 à 22:01, Nicolas Lalevée <nicolas.lalevee@hibnet.org> a écrit :

> I count 4 +1 from IPMC members and 2 +1 from mentors.

you should read PPMC instead of IPMC, obviously.

Nicolas

> The release is accepted. Thank you all.
> 
> I'll start a vote on @general.
> 
> Nicolas
> 
> Le 7 févr. 2013 à 20:27, Nicolas Lalevée <nicolas.lalevee@hibnet.org> a écrit
:
> 
>> Hi,
>> 
>> This is a call for a vote of the second tentative to release of EasyAnt 0.9. We are
releasing the plugins, the buildtypes, the skeletons and the core (the main distribution).
>> 
>> The svn tags are there:
>> http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
>> http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
>> http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
>> http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/
>> 
>> The released artifacts are there:
>> http://people.apache.org/~hibou/easyant-0.9-incubating/
>> 
>> The KEYS file is there:
>> http://svn.apache.org/repos/asf/incubator/easyant/KEYS
>> 
>> Please, cast your votes:
>> [ ] +1, I accept the release
>> [ ] +0, OK, but….
>> [ ] -1, I disapprove, because….
>> 
>> Nicolas
> 

I count 4 +1 from IPMC members and 2 +1 from mentors.
The release is accepted. Thank you all.

I'll start a vote on @general.

Nicolas

Le 7 févr. 2013 à 20:27, Nicolas Lalevée <nicolas.lalevee@hibnet.org> a écrit :

> Hi,
> 
> This is a call for a vote of the second tentative to release of EasyAnt 0.9. We are releasing
the plugins, the buildtypes, the skeletons and the core (the main distribution).
> 
> The svn tags are there:
> http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/
> 
> The released artifacts are there:
> http://people.apache.org/~hibou/easyant-0.9-incubating/
> 
> The KEYS file is there:
> http://svn.apache.org/repos/asf/incubator/easyant/KEYS
> 
> Please, cast your votes:
> [ ] +1, I accept the release
> [ ] +0, OK, but….
> [ ] -1, I disapprove, because….
> 
> Nicolas

Looks ok to me, +1

   ...ant

On Thu, Feb 7, 2013 at 7:27 PM, Nicolas Lalevée
<nicolas.lalevee@hibnet.org>wrote:

> Hi,
>
> This is a call for a vote of the second tentative to release of EasyAnt
> 0.9. We are releasing the plugins, the buildtypes, the skeletons and the
> core (the main distribution).
>
> The svn tags are there:
>
> http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
>
> http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
>
> http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/
>
> The released artifacts are there:
> http://people.apache.org/~hibou/easyant-0.9-incubating/
>
> The KEYS file is there:
> http://svn.apache.org/repos/asf/incubator/easyant/KEYS
>
> Please, cast your votes:
> [ ] +1, I accept the release
> [ ] +0, OK, but….
> [ ] -1, I disapprove, because….
>
> Nicolas

Le 10 févr. 2013 à 07:25, Stefan Bodewig <bodewig@apache.org> a écrit :

> On 2013-02-07, Nicolas Lalevée wrote:
> 
>> The svn tags are there:
>> http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
>> http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
>> http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
>> http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/
> 
>> The released artifacts are there:
>> http://people.apache.org/~hibou/easyant-0.9-incubating/
> 
>> The KEYS file is there:
>> http://svn.apache.org/repos/asf/incubator/easyant/KEYS
> 
> +1 in general, well done.
> 
> some nitpicking (for future releases)
> 
> * the .md5.sha1 files look  bit odd :-)

oops. I will not publish them, obviously. :)

> * the checksums talk about easyant-foo while the files are called
>  apache-easyant-foo

I renamed them after the checksum. Unless there is some objection, I will fix the name in
the checksum before the vote on general@.

> * I assume you inted to have separate releases in the future, otherwise
>  I'd prefer a single tag rather than four of them

I consider here that there is a kind of simultaneous release of 4 components. And we may see
it as a lot more components because some individual plugin or buildtype could be release independently.
But for our sake for this first big release, I packaged them as one.

> * core's tag contains an "experiment" folder and eclipse formatting
>  rules not present in the source tarball.

Strange. We'll fix that in the next release.

> * the buildtypes, plugins and skeleton ZIPs uncompress directly into the
>  current dir rather than an easyant-… directory

We'll try to fix that in the next release.

Thanks!

Nicolas

On 2013-02-07, Nicolas Lalevée wrote:

> The svn tags are there:
> http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/

> The released artifacts are there:
> http://people.apache.org/~hibou/easyant-0.9-incubating/

> The KEYS file is there:
> http://svn.apache.org/repos/asf/incubator/easyant/KEYS

+1 in general, well done.

some nitpicking (for future releases)

* the .md5.sha1 files look  bit odd :-)
 
* the checksums talk about easyant-foo while the files are called
  apache-easyant-foo

* I assume you inted to have separate releases in the future, otherwise
  I'd prefer a single tag rather than four of them

* core's tag contains an "experiment" folder and eclipse formatting
  rules not present in the source tarball.

* the buildtypes, plugins and skeleton ZIPs uncompress directly into the
  current dir rather than an easyant-... directory

Stefan

[X] +1, I accept the release

On Thu, Feb 7, 2013 at 8:27 PM, Nicolas Lalevée
<nicolas.lalevee@hibnet.org>wrote:

> Hi,
>
> This is a call for a vote of the second tentative to release of EasyAnt
> 0.9. We are releasing the plugins, the buildtypes, the skeletons and the
> core (the main distribution).
>
> The svn tags are there:
>
> http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
>
> http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
>
> http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/
>
> The released artifacts are there:
> http://people.apache.org/~hibou/easyant-0.9-incubating/
>
> The KEYS file is there:
> http://svn.apache.org/repos/asf/incubator/easyant/KEYS
>
> Please, cast your votes:
> [ ] +1, I accept the release
> [ ] +0, OK, but….
> [ ] -1, I disapprove, because….
>
>
[X] +1, I accept the release

-- 
Xavier Hanin - 4SH France - http://www.4sh.fr/
BordeauxJUG creator - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/

[X] +1, I accept the release
Le 7 févr. 2013 20:59, "Nicolas Lalevée" <nicolas.lalevee@hibnet.org> a
écrit :

>
> Le 7 févr. 2013 à 20:27, Nicolas Lalevée <nicolas.lalevee@hibnet.org> a
> écrit :
>
> > Hi,
> >
> > This is a call for a vote of the second tentative to release of EasyAnt
> 0.9. We are releasing the plugins, the buildtypes, the skeletons and the
> core (the main distribution).
> >
> > The svn tags are there:
> >
> http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
> >
> http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
> >
> http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
> >
> http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/
> >
> > The released artifacts are there:
> > http://people.apache.org/~hibou/easyant-0.9-incubating/
> >
> > The KEYS file is there:
> > http://svn.apache.org/repos/asf/incubator/easyant/KEYS
> >
> > Please, cast your votes:
> > [X] +1, I accept the release
>
> Nicolas
>
>
>

Le 7 févr. 2013 à 20:27, Nicolas Lalevée <nicolas.lalevee@hibnet.org> a écrit :

> Hi,
> 
> This is a call for a vote of the second tentative to release of EasyAnt 0.9. We are releasing
the plugins, the buildtypes, the skeletons and the core (the main distribution).
> 
> The svn tags are there:
> http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/
> 
> The released artifacts are there:
> http://people.apache.org/~hibou/easyant-0.9-incubating/
> 
> The KEYS file is there:
> http://svn.apache.org/repos/asf/incubator/easyant/KEYS
> 
> Please, cast your votes:
> [X] +1, I accept the release

Nicolas

Hi,

This is a call for a vote of the second tentative to release of EasyAnt 0.9. We are releasing
the plugins, the buildtypes, the skeletons and the core (the main distribution).

The svn tags are there:
http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/

The released artifacts are there:
http://people.apache.org/~hibou/easyant-0.9-incubating/

The KEYS file is there:
http://svn.apache.org/repos/asf/incubator/easyant/KEYS

Please, cast your votes:
[ ] +1, I accept the release
[ ] +0, OK, but….
[ ] -1, I disapprove, because….

Nicolas

Le 1 févr. 2013 à 13:18, Stefan Bodewig <bodewig@apache.org> a écrit :

> On 2013-01-31, ant elder wrote:
> 
>> One is i don't think there should be the '(TM)' after Easyant in the
>> NOTICE file. The other is that the Incubating DISCLAIMER file is
>> missing.
> 
> I don't think the (TM) too much will hurt but I'm afraid the missing
> disclaimer will make the vote fail on general@incubator.

hum, I missed that DISCLAMER file.

I have found some lines about it there:
http://incubator.apache.org/guides/branding.html
"For releases, the text SHOULD be included in a separate DISCLAIMER file stored alongside
the NOTICE and LICENSE files."

But for what I understand of the context, this is a "SHOULD" as there might be somewhere in
the doc that disclaimer. And we don't have it anywhere in the distribution.
So I'll roll out a new build with that fixed. And we'll fix the README too.

Cheers,
Nicolas

While talking about little issues, there are also several links in the
README file which are outdated (eg the reference to the old google group).

Xavier

On Thu, Jan 31, 2013 at 11:57 AM, ant elder <ant.elder@gmail.com> wrote:

> Well done guys, +1 from me.
>
> Theres a couple of issues i noticed, both of which i think its ok to fix
> later if theres a respin required or in the next release. One is i don't
> think there should be the '(TM)' after Easyant in the NOTICE file. The
> other is that the Incubating DISCLAIMER file is missing.
>
>    ...ant
>
>
> On Tue, Jan 29, 2013 at 11:41 PM, Nicolas Lalevée <
> nicolas.lalevee@hibnet.org> wrote:
>
> > Hi,
> >
> > This is a call for a vote of the release of EasyAnt 0.9. We are releasing
> > the plugins, the buildtypes, the skeletons and the core (the main
> > distribution).
> >
> > The svn tags are there:
> >
> >
> http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
> >
> >
> http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
> >
> >
> http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
> >
> http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/
> >
> > The released artifacts are there:
> > http://people.apache.org/~hibou/easyant-0.9-incubating/
> >
> > The KEYS file is there:
> > http://svn.apache.org/repos/asf/incubator/easyant/KEYS
> >
> > Please, cast your votes:
> > [ ] +1, I accept the release
> > [ ] +0, OK, but….
> > [ ] -1, I disapprove, because….
> >
> > Nicolas
> >
> >
>



-- 
Xavier Hanin - 4SH France - http://www.4sh.fr/
BordeauxJUG creator - http://www.bordeauxjug.org/
Apache Ivy Creator - http://ant.apache.org/ivy/

On 2013-01-31, ant elder wrote:

> One is i don't think there should be the '(TM)' after Easyant in the
> NOTICE file. The other is that the Incubating DISCLAIMER file is
> missing.

I don't think the (TM) too much will hurt but I'm afraid the missing
disclaimer will make the vote fail on general@incubator.

Otherwise +1 from me as well.

Stefan

Well done guys, +1 from me.

Theres a couple of issues i noticed, both of which i think its ok to fix
later if theres a respin required or in the next release. One is i don't
think there should be the '(TM)' after Easyant in the NOTICE file. The
other is that the Incubating DISCLAIMER file is missing.

   ...ant


On Tue, Jan 29, 2013 at 11:41 PM, Nicolas Lalevée <
nicolas.lalevee@hibnet.org> wrote:

> Hi,
>
> This is a call for a vote of the release of EasyAnt 0.9. We are releasing
> the plugins, the buildtypes, the skeletons and the core (the main
> distribution).
>
> The svn tags are there:
>
> http://svn.apache.org/repos/asf/incubator/easyant/plugins/tags/0.9-incubating/
>
> http://svn.apache.org/repos/asf/incubator/easyant/buildtypes/tags/0.9-incubating/
>
> http://svn.apache.org/repos/asf/incubator/easyant/skeletons/tags/0.9-incubating/
> http://svn.apache.org/repos/asf/incubator/easyant/core/tags/0.9-incubating/
>
> The released artifacts are there:
> http://people.apache.org/~hibou/easyant-0.9-incubating/
>
> The KEYS file is there:
> http://svn.apache.org/repos/asf/incubator/easyant/KEYS
>
> Please, cast your votes:
> [ ] +1, I accept the release
> [ ] +0, OK, but….
> [ ] -1, I disapprove, because….
>
> Nicolas
>
>