Re: archiving EasyAnt

2017-01-09 Thread Jean-Louis Boudart
When migrating the project from selfhosted to apache, we asked ourself
where to host the plugins artifacts, there was some discussion to store
them in apache's nexus instance, but it was not really designed for.
Easyant plugins are not distributed as jar, so maven layout was not really
applicable.
There was also other plugins that couldn't be hosted on ASF side mostly
because of incompatible licenses, and we wanted to have one entrypoint to
fetch both "Apache plugins" and "non Apache plugins".
So we started evaluating our options including moving from selfhosted to
bintray [1], we kickstarted it but never finished the transition (mostly
lack of time on my side).

Not sure it would be to complex to finish this migration if it still make
sense.

That's why i said "for good of bad reasons" in my previous emails :).


[1]
http://ant.1045680.n5.nabble.com/Evaluating-Bintray-as-a-distribution-platform-for-easyant-plugins-td5714096.html

2017-01-06 8:03 GMT+01:00 Jan Matèrne (jhm) <apa...@materne.de>:

> > Even if i understand the purpose of archiving project without too much
> > activity i don't get the point of shutting down home page and all
> > related stuff (including old blog or even the domain name).
> >
> > For good or bad reason easyant build still rely on repo.easyant.org
> > (see https://github.com/apache/ant-easyant-
> > core/blob/master/ivysettings.xml  and related discussion
> > http://ant.1045680.n5.nabble.com/Evaluating-Bintray-as-a-distribution-
> > platform-for-easyant-plugins-td5714096.html).
> > Note that with the sources on apache side we should still be able to
> > rebuild everything.
> >
> > I always thought apache projects needs to be "buildable"  during long
> > (that's why we have dist.apache.org and archive.apache.org) available,
> > but what is the point of having them available if we even don"t have
> > the available ressources to use it like the website/doc and so on ?? I
> > mean all this contribute to the history of the project and turning off
> > all those components/resource will clearly definitively kill the
> > project.
> >
> > I may be nostalgic on that topic but do we really want to do that ?
> >
> > If you all believe we should stop thoses resources/components down,
> > then fine i'll turn off everything, otherwise i will try to keep them
> > up  (domain included) as much as i can.
> >
> > WDYT ?
>
>
> I wasn't aware that the *.easyant.org resources were required for
> building EA.
> Being able to build even an archived project is valuable as you said -
> even if _I_ think,
> that we don't get new committers ...
>
> But when these resources are required for building EA, why aren't they
> hosted on Apache infrastructure?
> ATM we rely on external resources...
>
>
> Jan
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


-- 
Jean Louis Boudart


Re: archiving EasyAnt

2017-01-09 Thread Jean-Louis Boudart
2017-01-07 19:45 GMT+01:00 Stefan Bodewig <bode...@apache.org>:

> On 2017-01-05, Jean-Louis Boudart wrote:
>
> > I'm a little bit puzzled. I still believe there some room to a build tool
> > as easyant, and i expect that in a near future fresh blood will come and
> > resurect the project.
>
> I really wish you had said this when we voted on retiring EasyAnt.
>
My bad  :/



>
> > Even if i understand the purpose of archiving project without too much
> > activity i don't get the point of shutting down home page and all related
> > stuff (including old blog or even the domain name).
>
> There certainly is no reason to remove the old blog and if you want to
> keep the infrastructure intact this is certainly your choice. The
> services you host looked as if they would become obsolete with the
> retirement of EasyAnt, I think Jan suggested you remove them rather than
> request it.
>
No pb for that :)




>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


-- 
Jean Louis Boudart


Re: archiving EasyAnt

2017-01-05 Thread Jean-Louis Boudart
Hi,

I'm a little bit puzzled. I still believe there some room to a build tool
as easyant, and i expect that in a near future fresh blood will come and
resurect the project.

Even if i understand the purpose of archiving project without too much
activity i don't get the point of shutting down home page and all related
stuff (including old blog or even the domain name).

For good or bad reason easyant build still rely on repo.easyant.org (see
https://github.com/apache/ant-easyant-core/blob/master/ivysettings.xml  and
related discussion
http://ant.1045680.n5.nabble.com/Evaluating-Bintray-as-a-distribution-platform-for-easyant-plugins-td5714096.html).
Note that with the sources on apache side we should still be able to
rebuild everything.

I always thought apache projects needs to be "buildable"  during long
(that's why we have dist.apache.org and archive.apache.org) available, but
what is the point of having them available if we even don"t have the
available ressources to use it like the website/doc and so on ?? I mean all
this contribute to the history of the project and turning off all those
components/resource will clearly definitively kill the project.

I may be nostalgic on that topic but do we really want to do that ?

If you all believe we should stop thoses resources/components down, then
fine i'll turn off everything, otherwise i will try to keep them up
 (domain included) as much as i can.

WDYT ?


2017-01-05 15:15 GMT+01:00 Jan Matèrne (jhm) <apa...@materne.de>:

> Current status:
>
> Jan
>
>
> Retire: Version Control
> ---
> Most of our source code is in git, only "site" and "sandbox" use
> subversion.
>
> --> only git for sources. Homepage in svn.
> --> update EA-homepage
> --> Should we only place a note on the hp or completely remove them.
> I prefer removing the complete homepage.
> --> done
>
> https://git-wip-us.apache.org/repos/asf
>   ant-easyant-buildtypes.gitApache EasyAnt build types
>   ant-easyant-core.gitApache EasyAnt core
>   ant-easyant-easyant4e.git Apache EasyAnt for Eclipse
>   ant-easyant-plugins.git Apache EasyAnt plugins
>   ant-easyant-skeletons.git Apache EasyAnt skeletons
>   ant-easyant-tasks.git Apache EasyAnt tasks
>
>
> Ask infra to make the repository read-only.
> --> asked infra per https://issues.apache.org/jira/browse/INFRA-13230
> --> done
>
>
> Retire: Issue Tracker
> -
> If the subproject/component has its own issue tracker we have to close
> that.
> It is enough to make it read-only, so these information are longer
> available.
> --> open; use Jira EASYANT
> --> asked infra per https://issues.apache.org/jira/browse/INFRA-13225
>
>
> Retire: Announcement
> 
> We have to announce the retirement of the subproject at dev@ant,
> announce@apache and the Ant main page.
>text proposal:
>"
>The Ant PMC voted [1] to archive the EasyAnt subproject and all its
>modules. This means that all its resources are removed or made read only
>and no further development will be done.
>It also means that, if a community grows, the subproject could
> reactivated [2].
>
>[1]  http://mail-archives.apache.org/mod_mbox/ant-dev/201612.
> mbox/ajax/%3C000301d25510%2433d37720%249b7a6560%24%40de%3E
>[2]  http://ant.apache.org/processes.html#Reactivate%20a%
> 20subproject%20or%20component
>"
> --> done
> --> open: announcement on a...@apache.org (requires sending from Apache
> account)
>
>
>
> Retire: Releases
> 
> The last released artifacts, if any, should be removed from the Apache
> distribution server. To do so, remove any artifact related to the retired
> subproject in https://dist.apache.org/repos/dist/release/ant/ (it is
> managed
> with subversion: https://dist.apache.org/repos/dist/release/incubator/
> easyant/).
> --> open, doesnt have write privilege.
> --> could someone else remove that directory?
>
>
> Retire: Free Further Resources
> --
> Maybe a subproject locks further resources (update-site, ...). So we have
> to
> unblock them.
> --> open:
>There is a domain "easyant.org":
>www.easyant.org: redirects to ea@ant homepage
>blogs.easyant.org: blog system (last entry 2013)
>repo.easyant.org: an Artifactory instance
>
>Who owns that domain?
>   Registrant Name: Jean-Louis Boudart
>
>Jean-Louis: could you remove the services and the domain?
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


-- 
Jean Louis Boudart


Re: [VOTE] Release Ant 1.10.0 based on RC1

2016-12-30 Thread Jean-Louis Boudart
+1 here

2016-12-30 14:45 GMT+01:00 Paul King <pa...@asert.com.au>:

> +1 (non-binding)
> I checked the checksums and signature of the source zip.
> I ran Groovy's master branch against this version including its
> groovy-ant test suite.
> I must admit to not having followed much recent discussion on the dev
> mailing list. Just as an aside for future reference, I thought perhaps
> more discussion of the difference between versions would be useful in
> the release notes or manual. I initially assumed that 1.10.0 followed
> 1.9.8 but the split is really at 1.9.7 IIUC. In particular, I found
> having the 1.9.8 section above the 1.10.0 section a little confusing
> in the README file:
> https://dist.apache.org/repos/dist/dev/ant/README.html
> It's certainly not worth redoing the release for and I assume the
> build process just prepends - it was just a little strange having them
> out of order.
>
> Cheers, Paul.
>
> On Tue, Dec 27, 2016 at 5:07 PM, Stefan Bodewig <bode...@apache.org>
> wrote:
> > Hi all
> >
> > I've created a release candidate for 1.10.0:
> >
> > git tag: ANT_1.10.0_RC1
> >  on commit: ffcbcd7
> > tarballs: https://dist.apache.org/repos/dist/dev/ant/
> >   revision: 17588
> > Maven artifacts:
> > https://repository.apache.org/content/repositories/
> orgapacheant-1011/org/apache/ant/
> >
> > This Vote will be open at least for 72 hours and close no earlier than
> > 2016-12-30 7:00UTC.
> >
> > Cheers
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


-- 
Jean Louis Boudart


Re: [VOTE] Release Ant 1.9.8 based on RC1

2016-12-30 Thread Jean-Louis Boudart
+1 here

2016-12-30 14:35 GMT+01:00 Paul King <pa...@asert.com.au>:

> +1 (non-binding)
> I checked this version against Groovy's GROOVY_2_4_X and master branches.
> Groovy uses some ant features internally and also has a groovy-ant
> module with an accompanying test suite.
>
> Cheers, Paul.
>
> On Mon, Dec 26, 2016 at 7:04 AM, Stefan Bodewig <bode...@apache.org>
> wrote:
> > Hi all
> >
> > I've created a release candidate for 1.9.8:
> >
> > git tag: ANT_198_RC1
> >  on commit: 0e20ef3
> > tarballs: https://dist.apache.org/repos/dist/dev/ant/
> >   revision: 17572
> > Maven artifacts:
> >   https://repository.apache.org/content/repositories/
> orgapacheant-1010/org/apache/ant/
> >
> > Given the time of the year this Vote will be open at least for 96 hours
> > and close no earlier than 2016-12-29 21:00UTC.
> >
> > Cheers
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
>
> ---------
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


-- 
Jean Louis Boudart


Re: VOTE Retire IvyDE

2016-12-06 Thread Jean-Louis Boudart
+1

Le 6 déc. 2016 6:51 PM, "Nicolas Lalevée"  a
écrit :

> +1
>
> Nicolas
>
> > Le 6 déc. 2016 à 17:22, Stefan Bodewig  a écrit :
> >
> > On 2016-12-05, Jan Matèrne (jhm) wrote:
> >
> >> I start a vote for retiring IvyDE.
> >
> > +0
> >
> > The discussion in the "Ivy" thread makes me think we'd probably want to
> > update it with new Ivy releases, even if nothing else changes in
> > between.
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


Re: VOTE Retire EasyAnt subproject

2016-12-06 Thread Jean-Louis Boudart
+1

2016-12-07 1:05 GMT+01:00 Conor MacNeill <co...@apache.org>:

> +1
>
> Conor
>
>
> On 5 December 2016 at 18:04, Jan Matèrne (jhm) <apa...@materne.de> wrote:
> > I start a vote for retiring EasyAnt and all its components:
> >
> > - core
> >
> > - buildtypes
> >
> > - plugins
> >
> > - skeletons
> >
> > - tasks
> >
> > - easyant4e
> >
> >
> >
> > We never had a real release after the incubator.
> >
> > The last 'real' activity in vcs was in 09/2015 for EA-Core and 07/2013
> for
> > EA4E.
> >
> >
> >
> > It seems that we havent the community, committers and PMC to hold this
> > subproject.
> >
> >
> >
> > The general procedure is described in http://ant.apache.org/
> processes.html.
> >
> >
> >
> >
> >
> > I start with my +1.
> >
> >
> >
> >
> >
> > Jan
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>


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


Re: [VOTE] Release Ant 1.9.7 based on RC1

2016-04-11 Thread Jean-Louis Boudart
+1

2016-04-11 16:40 GMT+02:00 Maarten Coene <maarten_co...@yahoo.com.invalid>:

> +1
> Maarten
>
>   Van: Stefan Bodewig <bode...@apache.org>
>  Aan: dev@ant.apache.org
>  Verzonden: zaterdag 9 april 12:03 2016
>  Onderwerp: [VOTE] Release Ant 1.9.7 based on RC1
>
> Hi all
>
> I've created a release candidate for 1.9.7:
>
> git tag: ANT_197_RC1
> on commit: cecbf5c
> tarballs: https://dist.apache.org/repos/dist/dev/ant/
>   revision: 13103
> Maven artifacts:
>
> https://repository.apache.org/content/repositories/orgapacheant-1009/org/apache/ant/
>
> Vote will be open at least for 72 hours and close no earlier than
> 2016-04-12
> 10:00UTC.
>
> Cheers
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
>
>
>



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


Re: [RESULT] [VOTE] Stephen Haberman as a committer

2015-10-12 Thread Jean-Louis Boudart
Welcome on board :)

2015-10-12 14:49 GMT+02:00 Stephen Haberman <stephen.haber...@gmail.com>:

> Thanks for the vote of confidence, everyone; I'm looking forward to helping
> out!
>
> - Stephen
>
>
> On Sun, Oct 11, 2015 at 4:52 AM, Conor MacNeill <co...@apache.org> wrote:
>
> > The vote has now run for a week. The results are as follows:
> >
> > +1 (8 votes)
> > Conor MacNeill
> > Maarten Coene
> > Charles Duffy
> > Jean-Louis Boudart
> > Stefan Bodewig
> > Antoine Levy Lambert
> > Nicolas Lalevée
> > Martin Gainty
> >
> > 0  (1 vote)
> > Rm Beer
> >
> > -1 (0 votes)
> >
> > The vote is, therefore, successful and Stephen is now an Ant committer.
> >
> > Thanks
> > Conor'
> >
> > ---------
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
> >
>



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


Re: [VOTE] Stephen Haberman as a committer

2015-10-05 Thread Jean-Louis Boudart
+1

2015-10-05 13:18 GMT+02:00 Martin Gainty <mgai...@hotmail.com>:

> +1
> Martin
> _
>
> > Date: Mon, 5 Oct 2015 09:28:43 +
> > From: maarten_co...@yahoo.com.INVALID
> > To: dev@ant.apache.org
> > Subject: Re: [VOTE] Stephen Haberman as a committer
> >
> > +1
> > Maarten
> >
> >   Van: Conor MacNeill <co...@apache.org>
> >  Aan: Ant Developers List <dev@ant.apache.org>
> >  Verzonden: maandag 5 oktober 11:06 2015
> >  Onderwerp: [VOTE] Stephen Haberman as a committer
> >
> > I would like to nominate Stephen Haberman as a committer. Stephen has
> > submitted a number of well tested patches to the Ivy codebase. I
> > believe adding Stephen would strengthen the committer-base,
> > particularly for the Ivy Sub-project.
> >
> > Please vote
> >
> > [ ] +1 Add Stephen as a committer
> > [ ] -1 Disagree
> > [ ] +0 - Don't care.
> >
> > I will start proceedings with my +1
> >
> > Thanks
> > Conor
> >
> > ---------
> > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> > For additional commands, e-mail: dev-h...@ant.apache.org
> >
> >
> >
> >
>
>



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


Re: Looking to contribute

2015-07-16 Thread Jean-Louis Boudart
The best you can do to help us would be to try to submit patches either via
JIRA attachemnet or via pull requests.

Let me know if you need some more informations.

2015-07-16 14:06 GMT+02:00 Jean-Louis Boudart jeanlouis.boud...@gmail.com:

 Hi,

 Current java minimum version is defined in build.properties[1] of the
 project and is currently set to 1.4.
 Considering that Ant upgrade miminal java version to java 1.5 we should
 probably do the same on ivy.

 [1] https://github.com/apache/ant-ivy/blob/1.4.x/build.properties

 2015-07-16 6:23 GMT+02:00 Jaikiran Pai jai.forums2...@gmail.com:

 I'm thinking of contributing to the Ivy project. I had a quick look at
 the JIRAs that are open and also have checked out the latest source code
 from git. Before starting off with anything, I would like to know what is
 the Java version that should be used by contributors for code
 contributions? I couldn't find this in any document that I read (I can send
 a patch to the docs itself when I know the answer).

 -Jaikiran

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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




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


Re: Looking to contribute

2015-07-16 Thread Jean-Louis Boudart
Hi,

Current java minimum version is defined in build.properties[1] of the
project and is currently set to 1.4.
Considering that Ant upgrade miminal java version to java 1.5 we should
probably do the same on ivy.

[1] https://github.com/apache/ant-ivy/blob/1.4.x/build.properties

2015-07-16 6:23 GMT+02:00 Jaikiran Pai jai.forums2...@gmail.com:

 I'm thinking of contributing to the Ivy project. I had a quick look at the
 JIRAs that are open and also have checked out the latest source code from
 git. Before starting off with anything, I would like to know what is the
 Java version that should be used by contributors for code contributions? I
 couldn't find this in any document that I read (I can send a patch to the
 docs itself when I know the answer).

 -Jaikiran

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Release Ant 1.9.6 based on RC1

2015-06-29 Thread Jean-Louis Boudart
+1

2015-06-29 11:32 GMT+02:00 Stefan Bodewig bode...@apache.org:

 Hi all

 I've created a release candidate for 1.9.6:

 git tag: ANT_196_RC1
  hash: a143e2d3a
  on commit: b09976c
 tarballs: https://dist.apache.org/repos/dist/dev/ant/
   revision: 9551
 Maven artifacts:

 https://repository.apache.org/content/repositories/orgapacheant-1008/org/apache/ant/

 Vote will be open at least for 72 hours and close no earlier than Thu
 2nd July 2015 9:30UTC.

 Cheers

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Release Ant 1.9.5 based on RC1

2015-06-01 Thread Jean-Louis Boudart
+1

2015-05-31 16:46 GMT+02:00 Stefan Bodewig bode...@apache.org:

 Hi all

 I've created a release candidate for 1.9.5:

 git tag: ANT_195_RC1
  hash: 54ac2fedd
  on commit: ea7bf28
 tarballs: https://dist.apache.org/repos/dist/dev/ant/
   revision: 9181
 Maven artifacts:

 https://repository.apache.org/content/repositories/orgapacheant-1007/org/apache/ant/

 Vote will be open at least for 72 hours and close no earlier than Wed
 3rd June 2015.

 Cheers

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Generating EasyAnt website

2015-01-22 Thread Jean-Louis Boudart
Hi Nicolas,

Check at the module.ant in the project there is a target there (which
unfortunatly doesn’t contain description) named “generate-site”.

 target name=generate-site depends=xooki:generate
extensionOf=publish-shared

Like ant when you type “easyant -p” you only see target with descriptions.

Cheers,
​

2015-01-22 23:23 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:

 Hi,

 I tried to fixed the issues raised by Sebb about the links in EasyAnt’s
 website and I got issues.

 I am not sure which target should be called to get things generated. The
 command « easyant -p » is listing the usual targets for a project with a
 bunch of code, but this is not helpful and unrelated to what I want to do
 with the sources of a website. Looking at the source of the build, I can
 see some specific targets, but nothing get actually generated in the «
 production » folder. Any hint on how to generate the site ?

 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: xooki to asciidoc, a proof of concept

2014-12-30 Thread Jean-Louis Boudart
Hi Nicolas,

Definitively yes !

I was trying a similar approach with Jelly/markdown, but due to several
issues and  lack of time i stopped there.
I'm fine with asciidoc.

Could you tell us how you imagine the next steps ?
Will xooki only be used to produced toc ?
What will be the flow to edit documentation pages ?

2014-12-29 23:21 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:

 Hi,

 I like xooki because it manages well the templating of the web pages, and
 it manage well how to build a toc. I hate when documentation is not «
 browsable », like in a wiki, and xooki handle it well.

 But is is quite slow, generating Ivy’s documentation can takes minutes.
 And on macos jrunscript is considered as a graphical app, so it get the
 focus. Launching it repeatedly makes the Mac unusable because every few
 second there is a new jrunscript app getting the focus.
 And the only web browser in which you can do inline editing is Firefox. It
 is a good web browser but unfortunately it is not my default one.

 Manually rewriting the entire doc in another template engine is out the
 question. And I don’t want to lose the automatic build of the toc.

 So, as a defi, I wondered if I could make xooki.js generate something in a
 template language rather than .html, and still generate that toc.

 I don’t know much any template language, even Markdown. On paper, asciidoc
 looks better to me, and some Linus recommends it, so let’s try it so I can
 have a little experience with it.

 A few hours of hacking later, doing dirty code in js, using Asciidoctor,
 coming down to write some Ruby (oh my!), I have something working. Hence my
 last commit in a dedicated branch in Ivy: xooki2asciidoc

 You can test it. To generate the asciidoc files:
 ant -f build-doc.xml generate-asciidoc
 To generate the html files from the asciidoc files (in few seconds!):
 ant -f build-doc.xml generate-doc
 And open build/doc/index.html to see the result

 This is a proof of concept, the conversion of the html tags barely works,
 but the toc is functional.

 So what do you think ? Would you consider changing of template language ?
 If so would it be asciidoc ?

 Is there any objection ? I spent some time on it for fun (and passing time
 because of some quite late trains), I won’t mind if this is thrown away;
 but I would like to know if there are some so I won’t continue it.

 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Ivy 2.4.0 Release - take 2

2014-12-22 Thread Jean-Louis Boudart
Sorry for the late answer

+1

2014-12-18 12:12 GMT+01:00 Maarten Coene maarten_co...@yahoo.com.invalid:

 +1

 Maarten


 
 Van: Nicolas Lalevée nicolas.lale...@hibnet.org
 Aan: Ant Developers List dev@ant.apache.org
 Verzonden: zaterdag 13 december 17:45 2014
 Onderwerp: [VOTE] Ivy 2.4.0 Release - take 2


 I have built a second release candidate for Ivy 2.4.0

 The svn tag of this release is:
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=0b9db35ee7a94a719e538b04122b86cb997f3a17

 The artifacts has been published to:
 https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7405

 Do you vote for the release of these binaries?

 [ ] Yes
 [ ] No

 Regards,

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [CANCELED][VOTE] Release Ivy 2.4.0

2014-12-09 Thread Jean-Louis Boudart
I thought it was possible as it was done for xooki (which doesn't seems to
have trunk/tags/branches structure see
https://issues.apache.org/jira/browse/INFRA-7816).

If we need to find another solution then we should probably duplicate
styles on git as they do not move too often. We can then improve this by
adding some automation to replicate changes from our new reference (GIT) in
svn website like Nicolas has done when handling documentation of released
versions.

2014-12-09 5:33 GMT+01:00 Antoine Levy Lambert anto...@gmx.de:

 On the infrastructure list Gavin wrote that infra is not able to create
 the mirror of the styles folder of the ivy doc that has been requested by
 Jean-Louis.

 The reason being that infra can only create a mirror from a structure
 having tags and trunk.

 @Jean-Louis, would creating a new git repository that we would populate
 manually work ?

 Regards,

 Antoine


 On Dec 3, 2014, at 5:05 PM, JBaruch jbar...@jfrog.com wrote:

  documentation added.
 
  Baruch.
 
  --
  JFrog Developer Advocate
  www.jfrog.com
  +972544954353
  @jbaruch https://twitter.com/jbaruch/
  http://linkd.in/jbaruch
 
  On Wed, Dec 3, 2014 at 1:37 PM, JBaruch jbar...@jfrog.com wrote:
 
  Perfect, we are on it.
  On 3 Dec 2014 12:29, Nicolas Lalevée nicolas.lale...@hibnet.org
 wrote:
 
  I would still would like some doc.
 
  The doc in the code source is still broken and it make it difficult to
  know how it is rendered.
  In the mean time time, you could write a page. I will then ensure
 myself
  that is proper included in the doc and rendered when the build will be
  fixed. You can take this file as an exemple:
 
 
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=doc/resolver/ibiblio.html;h=80057c4816a3cabc79bee70c961c57adcee29d11;hb=HEAD
  
 
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=blob;f=doc/resolver/ibiblio.html;h=80057c4816a3cabc79bee70c961c57adcee29d11;hb=HEAD
 
 
  Nicolas
 
  Le 2 déc. 2014 à 22:56, JBaruch jbar...@jfrog.com a écrit :
 
  Can we use this opportunity to sneak IVY-1474 in?
 
  Baruch.
 
  --
  JFrog Developer Advocate
  www.jfrog.com
  +972544954353
  @jbaruch https://twitter.com/jbaruch/
  http://linkd.in/jbaruch
 
  On Tue, Dec 2, 2014 at 6:19 PM, Nicolas Lalevée 
  nicolas.lale...@hibnet.org
  wrote:
 
  It was so obvious that this release candidate should be canceled
 that I
  forgot to officially set it. Here it is.
 
  I see that the infra ticket is resolved. Jean-Louis spotted some
 issues
  with it though. But I guess we will retry very soon.
 
  Nicolas
 
  Le 9 nov. 2014 à 17:56, Nicolas Lalevée nicolas.lale...@hibnet.org
 
  a
  écrit :
 
  I have built a release candidate for Ivy 2.4.0
 
  The git tag of this release is:
 
 
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=b7f132a46601cdecfc631052818cab7f498078d2
 
  The artifacts has been published to:
  https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7093
 
  Do you vote for the release of these binaries?
 
  [ ] Yes
  [ ] No
 
  Regards,
  Nicolas
 
 
 
 -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [CANCELED][VOTE] Release Ivy 2.4.0

2014-12-09 Thread Jean-Louis Boudart
Thanks for pointers stefan, i never used svn2git but i'll have a closer
look.

We need to choose what will be our reference.

Let me give you some context :
This directory containing styles (css,etc...) is used by both website
(which is still in svn and published via svnpubsub) and project
documentation (which is in ivy's git repository). As infra was proposing
git-svn mirror it was a good compromise. Website could live using
svn:externals to fetch appropriate files, and project documentation could
use git submodules.

If we can't have this svn mirror i don't think we could move thoses file in
a new git repository as website will not be able to access it.

The ideal solutions to all this headaches would probably to have everything
in git (including ivy's website), unfortunatly as far as i know we can't
publish website via git @ASF for the moment. Infra offers a gitpubsub
feature but i read somewhere that we can't use it to publish websites.

Considering we're talking about a few files that doesn't move too often i
was suggesting duplicating them by hand and/or automating it via a script
during the release process.



2014-12-09 9:59 GMT+01:00 Stefan Bodewig bode...@apache.org:

 On 2014-12-09, Jean-Louis Boudart wrote:

  If we need to find another solution then we should probably duplicate
  styles on git as they do not move too often. We can then improve this by
  adding some automation to replicate changes from our new reference (GIT)
 in
  svn website like Nicolas has done when handling documentation of released
  versions.

 I've migrated xmlunit from svn to git[1] using svn2git[2] quite easily,
 so starting with a fresh git repo and the pushing such a migrated code
 base would preserve all history.

 If you really need to keep two copies around, then svn2git --rebase
 might help with it - it would certainly be a manual step.

 Stefan

 [1] https://github.com/xmlunit/xmlunit
 [2] https://github.com/nirvdrum/svn2git

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Release Ivy 2.4.0

2014-11-14 Thread Jean-Louis Boudart
I asked INFRA to create a git readonly mirror to this directory (
https://issues.apache.org/jira/browse/INFRA-8627).

Stay tuned!




2014-11-12 20:13 GMT+01:00 Maarten Coene maarten_co...@yahoo.com.invalid:

 The style folder was included using svn:externals and is part of the ivy
 site:
 https://svn.apache.org/repos/asf/ant/site/ivy/sources/style/

 We should rebuild the release with this folder included imho.

 Maarten



 
  Van: Jean-Louis Boudart jeanlouis.boud...@gmail.com
 Aan: Ant Developers List dev@ant.apache.org; Maarten Coene 
 maarten_co...@yahoo.com
 Verzonden: woensdag 12 november 10:05 2014
 Onderwerp: Re: [VOTE] Release Ivy 2.4.0


 +1 for expect the style folder

 Where does this style folder is  ? Is it somewhere in SVN / GIT ?


 2014-11-10 0:24 GMT+01:00 Maarten Coene maarten_co...@yahoo.com.invalid:

  Thank you for creating the release Nicolas :-)
 
  I've noticed that the style directory is missing in the documentation
 in
  apache-ivy-2.4.0-bin.zip (and probably the others too).
  This makes the documentation inside these binaries look a bit 'basic'.
 
  Maarten
 
 
 
  
   Van: Nicolas Lalevée nicolas.lale...@hibnet.org
  Aan: Ant Developers List dev@ant.apache.org
  Verzonden: zondag 9 november 17:56 2014
  Onderwerp: [VOTE] Release Ivy 2.4.0
 
 
  I have built a release candidate for Ivy 2.4.0
 
  The git tag of this release is:
 
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=b7f132a46601cdecfc631052818cab7f498078d2
 
  The artifacts has been published to:
  https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7093
 
  Do you vote for the release of these binaries?
 
  [ ] Yes
  [ ] No
 
  Regards,
  Nicolas
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 



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




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


Re: [VOTE] Release Ivy 2.4.0

2014-11-12 Thread Jean-Louis Boudart
+1 for expect the style folder

Where does this style folder is  ? Is it somewhere in SVN / GIT ?

2014-11-10 0:24 GMT+01:00 Maarten Coene maarten_co...@yahoo.com.invalid:

 Thank you for creating the release Nicolas :-)

 I've noticed that the style directory is missing in the documentation in
 apache-ivy-2.4.0-bin.zip (and probably the others too).
 This makes the documentation inside these binaries look a bit 'basic'.

 Maarten



 
  Van: Nicolas Lalevée nicolas.lale...@hibnet.org
 Aan: Ant Developers List dev@ant.apache.org
 Verzonden: zondag 9 november 17:56 2014
 Onderwerp: [VOTE] Release Ivy 2.4.0


 I have built a release candidate for Ivy 2.4.0

 The git tag of this release is:
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=b7f132a46601cdecfc631052818cab7f498078d2

 The artifacts has been published to:
 https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0@7093

 Do you vote for the release of these binaries?

 [ ] Yes
 [ ] No

 Regards,
 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Commit Candidates for Ivy 2.4.x

2014-10-28 Thread Jean-Louis Boudart
Ok for me to make the next 2.4 from master.

2014-10-27 23:56 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:


 Le 26 oct. 2014 à 20:19, Nicolas Lalevée nicolas.lale...@hibnet.org a
 écrit :

 
  Le 26 oct. 2014 à 19:58, Jean-Louis Boudart jeanlouis.boud...@gmail.com
 a écrit :
 
  Hi Nicolas,
 
  My answers bellow.
 
  2014-10-26 19:18 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org
 :
 
  I have checked the branch 2.4.x. I have put back in the branch every
 thing
  that was obvious enough.
 
  There are some that may need to be merged back too, I would need some
  feedback about them.
 
  - IVY-1465 [1] doesn’t seem to be fully finished. One part is in the
  branch, the commit ‘3076802a’ [2] is not, and doesn’t apply cleanly.
 
  This commit looks like easy to merge manually, by the way what do you
 mean
  by doesn't apply cleanly » ?
 
  I did a cherry-pick and there were some conflict to resolve. I have to
 admit that I didn’t looked at what the conflict was.

 So I had a closer look to it. Something is actually going wrong, git is
 right about the patch not applying cleanly, some code is missing.

 As far as I could look around, 3076802a [1] needs 8d851390 (r1592624) [2].
 It was supposed to be merged by 57892b6e [3] but it doesn’t look as fully
 merged. For instance, PomModuleDescriptorBuilder is modified by 8d851390
 but not by 57892b6e.

 So I don’t trust much the state the 2.4.x branch. Maybe should we better
 make the next 2.4 from trunk ?

 Nicolas

 [1]
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=3076802a
 [2]
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=8d851390
 [3]
 https://git-wip-us.apache.org/repos/asf?p=ant-ivy.git;a=commit;h=57892b6e


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: git merge is generating a lot of mails

2014-10-28 Thread Jean-Louis Boudart
Can you tell us the command you use ?

Did you used squash option? Did you rebase ?

2014-10-28 22:55 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:

 As you can see on the notifications list, there is a nice bunch of mails,
 all generated from my one commit which merged the master of Ivy into the
 branch 2.4. I have hard time understand the rationale. Anyone more familiar
 with git than me have some explanation ?

 Note that I am not worried, I just like to understand what is going on.

 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Commit Candidates for Ivy 2.4.x

2014-10-26 Thread Jean-Louis Boudart
Hi Nicolas,

My answers bellow.

2014-10-26 19:18 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:

 I have checked the branch 2.4.x. I have put back in the branch every thing
 that was obvious enough.

 There are some that may need to be merged back too, I would need some
 feedback about them.

 - IVY-1465 [1] doesn’t seem to be fully finished. One part is in the
 branch, the commit ‘3076802a’ [2] is not, and doesn’t apply cleanly.

This commit looks like easy to merge manually, by the way what do you mean
by doesn't apply cleanly ?

- use https for maven repos [3]; should we merge it ?
 - and there is IVY-1491 [4]; should we merge it ?

I would say yes for both



 - and there are two commits which don’t seem to be related to any bug:
 ‘5063d256’ [5] and ‘a6b9ca3f’ [6].

They are not related to any bug, both are small improvement on API
introduced in 2.4-rc1. Not sure it make sense to have a bug for those one
but i can create one if you want.


Re: Updating Ivy's trunk doc in the site

2014-10-26 Thread Jean-Louis Boudart
Would it be possible to have everything on git ?
Looks like there is a gitpubsub feature available[1]

Another option could be to use svn client for github (but this relies on
github infra not ASF one :/) [2].

A manual solution could be to have website + released documentation on
svn. Git could still contains the trunk/master documentation (we only
publish it on the website when releasing).
During a release we could zip/export documentation and put it on svn.
Ideally all this could be probably done by an ant target.

We can ask infra to have svn read only mirror on our git repo but this
would make release process i think more complicated.

WDYT ?


[1] http://www.apache.org/dev/gitpubsub.html
[2] https://help.github.com/articles/support-for-subversion-clients/



2014-10-26 19:49 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:

 Now that the Ivy’s code source is in git, but the site is still managed in
 svn, how do we update the doc of Ivy trunk in the site ?
 How can I update this : http://ant.apache.org/ivy/history/trunk/index.html

 We’ll have a similar issue when we will release, we will need to publish
 the released doc.

 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Commit Candidates for Ivy 2.4.x

2014-10-26 Thread Jean-Louis Boudart
2014-10-26 20:19 GMT+01:00 Nicolas Lalevée nicolas.lale...@hibnet.org:



  - IVY-1465 [1] doesn’t seem to be fully finished. One part is in the
  branch, the commit ‘3076802a’ [2] is not, and doesn’t apply cleanly.
 
  This commit looks like easy to merge manually, by the way what do you
 mean
  by doesn't apply cleanly » ?

 I did a cherry-pick and there were some conflict to resolve. I have to
 admit that I didn’t looked at what the conflict was.

 So IVY-1465 is finished ? Should we mark it as fixed in 2.4 ?


Yes



  - and there are two commits which don’t seem to be related to any bug:
  ‘5063d256’ [5] and ‘a6b9ca3f’ [6].
 
  They are not related to any bug, both are small improvement on API
  introduced in 2.4-rc1. Not sure it make sense to have a bug for those one
  but i can create one if you want.

 Agreed, no need to create issues for that. My point is that since they are
 not associated with any bug, I guess they should not be merged ? But if
 these improvements are related to the API introduced in 2.4, then I guess
 they should ?

They should be merged.


What about including the two following ones ? :

   - IVY-1452 NullPointerException when accessing charset to invalid URL
   [1]
   - IVY-1474 Bintray resolver [2]

IVY-1452 is anoying issue that could easily be fixed, i tried the attached
patch and it fixes the issue.
IVY-1474 is new resolver for Bintray repository.

[1] https://issues.apache.org/jira/browse/IVY-1452
[2] https://issues.apache.org/jira/browse/IVY-1474


Re: Release of Ivy 2.4.0

2014-10-17 Thread Jean-Louis Boudart
Hi,

What can i do to assist you on this first release with git ?

2014-10-16 22:00 GMT+02:00 Josh Suereth joshua.suer...@gmail.com:

 If It helps, we had to move back to 2.3 because parent-pom-properties don't
 resolve correctly in 2.4.0-rc1 which broke a lot of our users.
 On Oct 15, 2014 6:28 PM, Maarten Coene maarten_co...@yahoo.com.invalid
 wrote:

  If I remember correctly, the 2.4.0-RC1 also introduced some other very
  annoying bugs, these fixes should be included in the 2.4.0 release as
 well
  imho.
 
  I whish I could help you with it Nicolas, but I also have too little time
  which will be needed for the first release on git.
  (In fact, my very very low activity is also caused by the fact that we
 are
  on git now in combination with the lack of time to learn how to use it
  properly)
 
 
  Maarten
 
 
 
  
   Van: Nicolas Lalevée nicolas.lale...@hibnet.org
  Aan: Ant Developers List dev@ant.apache.org
  Verzonden: woensdag 15 oktober 18:31 2014
  Onderwerp: Release of Ivy 2.4.0
 
 
  The last release of Eclipse has introduced a nasty bug [2], IvyDE is
  impacted, and the fix/work-around is in Ivy [2]. I think we should get a
  fix out very soon.
 
  And Ivy has been in RC for quite some time, I suggest we release it with
  also that fix, as the 2.4.0.
 
  This would be the first release done from git, my free time is quite
  limited, so don’t freak if I take some time to get out a release to be
  voted upon.
 
  Nicolas
 
  [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=445122
  [2] https://issues.apache.org/jira/browse/IVY-1487
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Release of Ivy 2.4.0

2014-10-17 Thread Jean-Louis Boudart
 Hi Josh,

This issue is supposed to be fixed on master branch could you take a
nightly build and give a try ?
You can find the latest nightly build here :
https://builds.apache.org/view/All/job/Ivy/lastStableBuild/

2014-10-16 22:00 GMT+02:00 Josh Suereth joshua.suer...@gmail.com:

 If It helps, we had to move back to 2.3 because parent-pom-properties don't
 resolve correctly in 2.4.0-rc1 which broke a lot of our users.
 On Oct 15, 2014 6:28 PM, Maarten Coene maarten_co...@yahoo.com.invalid
 wrote:

  If I remember correctly, the 2.4.0-RC1 also introduced some other very
  annoying bugs, these fixes should be included in the 2.4.0 release as
 well
  imho.
 
  I whish I could help you with it Nicolas, but I also have too little time
  which will be needed for the first release on git.
  (In fact, my very very low activity is also caused by the fact that we
 are
  on git now in combination with the lack of time to learn how to use it
  properly)
 
 
  Maarten
 
 
 
  
   Van: Nicolas Lalevée nicolas.lale...@hibnet.org
  Aan: Ant Developers List dev@ant.apache.org
  Verzonden: woensdag 15 oktober 18:31 2014
  Onderwerp: Release of Ivy 2.4.0
 
 
  The last release of Eclipse has introduced a nasty bug [2], IvyDE is
  impacted, and the fix/work-around is in Ivy [2]. I think we should get a
  fix out very soon.
 
  And Ivy has been in RC for quite some time, I suggest we release it with
  also that fix, as the 2.4.0.
 
  This would be the first release done from git, my free time is quite
  limited, so don’t freak if I take some time to get out a release to be
  voted upon.
 
  Nicolas
 
  [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=445122
  [2] https://issues.apache.org/jira/browse/IVY-1487
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: git commit: workwaround to fix unit tests as Hamcrest's IsCollectionContaining seems buggy

2014-08-28 Thread Jean-Louis Boudart
Thanks for the feedback Stefan :)


2014-08-28 17:40 GMT+02:00 Stefan Bodewig bode...@apache.org:

 On 2014-08-28, Stefan Bodewig wrote:

  On 2014-08-28, jlboud...@apache.org wrote:

  workwaround to fix unit tests as Hamcrest's IsCollectionContaining
 seems buggy

  actually, it is Hamcrest's isA matcher that is borked, stumbled over it
  myself a few times.

 and you can use

 new org.hamcrest.core.IsInstanceOf(MultiModuleLogger.class)

 as an alternative (which works, while the instanceOf factory method has
 the same problem as the isA matcher).

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Ivy-test jobs configuration in jenskins

2014-08-20 Thread Jean-Louis Boudart
Thanks Stefan :)


2014-08-20 9:07 GMT+02:00 Stefan Bodewig bode...@apache.org:

 On 2014-08-19, Jean-Louis Boudart wrote:

  I subscribe to thoses lists but it looks like i'm not authorized myself
 to
  perform this :) :

  modify_appgroups.pl hudson-jobadmin --add=jlboudart

 That's the step I said you'd need PMC chair powers for. :-)

 You should be set now.

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Ivy-test jobs configuration in jenskins

2014-08-19 Thread Jean-Louis Boudart
2014-08-19 17:49 GMT+02:00 Stefan Bodewig bode...@apache.org:

 On 2014-08-18, Jean-Louis Boudart wrote:

  Looks like ivy-tests can't run on ubuntu nodes as it try to use ant-1.7
  which is not installed there.

 Do you really need Ant 1.7 or would a later version do?  I don't think
 anybody of us has karma to install software on the build slaves, but it
 can certainly be done.


I don't think we need this specific version but ant 1.7+.
I can understand we can't install what we want on build slaves, but we
could change the version used. Jan updated this configuration and now
everything is working fine on both windows and ubuntu nodes.


  Can someone with sufficient karma fix this ?
  I even can't update configuration of the job :/

 For the last part, have you gone through the steps necessary to create a
 Jenkins account:
 http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account ?

 steps is really just a single step any PMC chairman can perform (I
 happen to be one) and you are required to subscribe to a few lists.


I'll try that thanks for the link.


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


Re: Ivy-test jobs configuration in jenskins

2014-08-19 Thread Jean-Louis Boudart
I subscribe to thoses lists but it looks like i'm not authorized myself to
perform this :) :

 modify_appgroups.pl hudson-jobadmin --add=jlboudart
 Password for 'jlboudart' (^D aborts):
 Insufficient access at /usr/local/bin/modify_group_members.pl line 102
 modify_group_members.pl failed: 255




2014-08-19 18:33 GMT+02:00 Jean-Louis Boudart jeanlouis.boud...@gmail.com:




 2014-08-19 17:49 GMT+02:00 Stefan Bodewig bode...@apache.org:

 On 2014-08-18, Jean-Louis Boudart wrote:

  Looks like ivy-tests can't run on ubuntu nodes as it try to use ant-1.7
  which is not installed there.

 Do you really need Ant 1.7 or would a later version do?  I don't think
 anybody of us has karma to install software on the build slaves, but it
 can certainly be done.


 I don't think we need this specific version but ant 1.7+.
 I can understand we can't install what we want on build slaves, but we
 could change the version used. Jan updated this configuration and now
 everything is working fine on both windows and ubuntu nodes.


  Can someone with sufficient karma fix this ?
  I even can't update configuration of the job :/

 For the last part, have you gone through the steps necessary to create a
 Jenkins account:
 http://wiki.apache.org/general/Jenkins#How_do_I_get_an_account ?

 steps is really just a single step any PMC chairman can perform (I
 happen to be one) and you are required to subscribe to a few lists.


 I'll try that thanks for the link.


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




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


Re: Build failed in Jenkins: Ivy-tests » JDK 1.5 (latest),Ubuntu #120

2014-08-19 Thread Jean-Louis Boudart
Both are now in SUCCESS thanks Jan.


2014-08-19 8:33 GMT+02:00 Jan Matèrne (jhm) apa...@materne.de:

 Changed the configuration from Ant 1.7.0 to Ant latest.
 -- same problem on Windows

 Changed Ant to Standard
 -- dont find ant.bat

 changed to ant-1.9.3
 -- build runs fine

 https://builds.apache.org/job/Ivy-tests/jdk=JDK%201.5%20%28latest%29,label=Windows/lastBuild/console

 The Ubuntu build is waiting for the next executor.


 Ant 1.9.4 is not available in the configuration dialog.


 Jan

  -Ursprüngliche Nachricht-
  Von: Apache Jenkins Server [mailto:jenk...@builds.apache.org]
  Gesendet: Montag, 18. August 2014 19:58
  An: notificati...@ant.apache.org
  Betreff: Build failed in Jenkins: Ivy-tests » JDK 1.5 (latest),Ubuntu
  #120
 
  See https://builds.apache.org/job/Ivy-
  tests/jdk=JDK%201.5%20(latest),label=Ubuntu/120/changes
 
  Changes:
 
  [jeanlouis.boudart] Minor change in pomModuleDescriptor, we expect to
  set extraInfo if key doesn't exist
 
  --
  Started by upstream project Ivy-tests build number 120 originally
  caused by:
   Started by upstream project Ivy build number 493  originally caused
  by:
Started by user jlboudart
  Building remotely on ubuntu-1 (Ubuntu ubuntu) in workspace
  https://builds.apache.org/job/Ivy-
  tests/jdk=JDK%201.5%20(latest),label=Ubuntu/ws/
  Cloning the remote Git repository
  Cloning repository https://git-wip-us.apache.org/repos/asf/ant-ivy.git
git init https://builds.apache.org/job/Ivy-
  tests/jdk=JDK%201.5%20(latest),label=Ubuntu/ws/
  Fetching upstream changes from https://git-wip-
  us.apache.org/repos/asf/ant-ivy.git
git --version
git fetch --tags --progress https://git-wip-
  us.apache.org/repos/asf/ant-ivy.git +refs/heads/*:refs/remotes/origin/*
git config remote.origin.url https://git-wip-
  us.apache.org/repos/asf/ant-ivy.git
git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/*
git config remote.origin.url https://git-wip-
  us.apache.org/repos/asf/ant-ivy.git
  Cleaning workspace
git rev-parse --verify HEAD
  No valid HEAD. Skipping the resetting
git clean -fdx
  Fetching upstream changes from https://git-wip-
  us.apache.org/repos/asf/ant-ivy.git
git fetch --tags --progress https://git-wip-
  us.apache.org/repos/asf/ant-ivy.git +refs/heads/*:refs/remotes/origin/*
  Checking out Revision a6b9ca3f71d44dbe2562e13d63e4b30fcaccdf50
  (origin/master)   git config core.sparsecheckout   git checkout -f
  a6b9ca3f71d44dbe2562e13d63e4b30fcaccdf50
git rev-list db5101c2334417462ece6bad55952f9964da79e6
git remote
git submodule init
git submodule sync
git config --get remote.origin.url
git submodule update --init --recursive
  FATAL: Cannot find executable from the chosen Ant installation Ant
  1.7.0
  Build step 'Invoke Ant' marked build as failure Recording test results


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [ivy] XmlModuleDescriptorWriterTest fails locally

2014-08-18 Thread Jean-Louis Boudart
Hi Stefan,

I have the same issue locally. But all tests passed on jenkins.
I've already spent a few hours on it but don't know where the real issue
came from. Any ideas are welcome.

2014-08-12 12:50 GMT+02:00 Stefan Bodewig bode...@apache.org:

 Hi

 XmlModuleDescriptorWriterTest uses String comparisons to compare XML
 files.  In one of the tests (testExtraInfosFromMaven) my local result
 contains some elements in a different order than expected (I get
 commons-collections after commons-logging).

 I could fix this by introducing a dependency on XMLUnit, by faking
 XMLUnit's behavior for the specific test or by ignoring the error (when
 I run the test, not inside the code).  Since I'll likely not run the
 tests too often, I'd prefer to leave the decision to people who really
 work on the code base.

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Ivy-test jobs configuration in jenskins

2014-08-18 Thread Jean-Louis Boudart
HI there,

Looks like ivy-tests can't run on ubuntu nodes as it try to use ant-1.7
which is not installed there.
Can someone with sufficient karma fix this ?
I even can't update configuration of the job :/

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


Re: Build failed in Jenkins: EasyAnt #175

2014-06-18 Thread Jean-Louis Boudart
Thanks !


2014-06-18 8:14 GMT+02:00 Jan Matèrne (jhm) apa...@materne.de:

 All blue now.

 Jan

  -Ursprüngliche Nachricht-
  Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
  Gesendet: Mittwoch, 18. Juni 2014 08:09
  An: 'Ant Developers List'
  Betreff: AW: Build failed in Jenkins: EasyAnt #175
 
  Changed the configuration
  SCM-Git::Additional Behaviour
  Advanced sub-modules behaviour
  Recursively update submodules = true
 
  Build successful
  Job failed due archiving issues (I removed the trunk in the path and
  resceduled a build).
 
 
  Jan
 
   -Ursprüngliche Nachricht-
   Von: Jean-Louis Boudart [mailto:jeanlouis.boud...@gmail.com]
   Gesendet: Dienstag, 17. Juni 2014 21:38
   An: Ant Developers List
   Betreff: Re: Build failed in Jenkins: EasyAnt #175
  
   Hi,
  
   I added xooki as easyant submodule to handle documentation.
   Unfortunatly jenkins doesn't seems to fetch submodules. I haven't
   enough karma there to manage job configuration, could someone with
   enough karma check the config to see if there is an option to fetch
   git submodules ?
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
  commands, e-mail: dev-h...@ant.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Build failed in Jenkins: EasyAnt #175

2014-06-17 Thread Jean-Louis Boudart
 
  [java] [ivy:install]   published meta-build to 
 https://builds.apache.org/job/EasyAnt/ws/target/main/classes/repository/core/org.apache.easyant.buildtypes/meta-build/0.9/meta-build.properties
 
  [java] [ivy:install]   published ivy to 
 https://builds.apache.org/job/EasyAnt/ws/target/main/classes/repository/core/org.apache.easyant.buildtypes/meta-build/0.9/meta-build.ivy
 
  [java] [ivy:install] :: install resolution report ::
  [java] [ivy:install] :: resolution report :: resolve 0ms :: artifacts
 dl 1525ms
  [java]
 -
  [java] |  |modules||
 artifacts   |
  [java] |   conf   | number| search|dwnlded|evicted||
 number|dwnlded|
  [java]
 -
  [java] |  default |   1   |   1   |   1   |   0   ||   2
   |   2   |
  [java]
 -
  [java]
  [java] prepare-distribution:
  [java] [mkdir] Created dir: 
 https://builds.apache.org/job/EasyAnt/ws/target/documentation
  [java]
  [java] stage-dist:
  [java] [mkdir] Created dir: 
 https://builds.apache.org/job/EasyAnt/ws/target/dist
  [java]  [copy] Copying 50 files to 
 https://builds.apache.org/job/EasyAnt/ws/target/dist
  [java] [mkdir] Created dir: 
 https://builds.apache.org/job/EasyAnt/ws/target/dist/lib
  [java]  [copy] Copying 5 files to 
 https://builds.apache.org/job/EasyAnt/ws/target/dist/lib
  [java]  [copy] Copying 1 file to 
 https://builds.apache.org/job/EasyAnt/ws/target/dist/lib
  [java]
  [java] BUILD FAILED
  [java] Dr Myrmex found an error when building easyant-core
  [java] * Where
  [java]
  [java] File :
 /home/jenkins/.easyant/easyant-cache/org.apache.easyant.plugins/xooki/ants/xooki-0.9.ant
  [java] Line : 78 column : 161
  [java]
  [java] * Dr Myrmex diagnostic
  [java]
  [java] Xooki skeleton has not been correctly setup. Run easyant
 org.apache.easyant.plugins#xooki:create-skeleton to generate a xooki
 skeleton.
  [java]
  [java]
  [java] * Recomendation ...
  [java]
  [java] Dr Myrmex suggest you to run easyant with -verbose or -debug
 option to get more details.
  [java]
  [java] Total time: 1 minute 8 seconds
  [java]
  [java] xooki:init:
  [java]   [taskdef] File 
 https://builds.apache.org/job/EasyAnt/ws/src/documentation/xooki/antlib.xml
 does not exist

 BUILD FAILED
 https://builds.apache.org/job/EasyAnt/ws/build.xml:75: Java returned: 1

 Total time: 2 minutes 22 seconds
 Build step 'Invoke Ant' marked build as failure
 [locks-and-latches] Releasing all the locks
 [locks-and-latches] All the locks released
 Archiving artifacts




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


Fwd: git commit: Add xooki as submodule

2014-06-12 Thread Jean-Louis Boudart
I've just added xooki as git submodule of ivy on master branch. Submodule
currently point to latest commit of xooki.

A few things :
 * to update xooki submodule we need to use git submodule update command
 * for those who wants a fresh clone including submodule you can use
--recursive option (git clone --recursive git://repo.git)
 * for those who already have cloned ivy repo just use git submodule init
command
 * for other stuff check the documentation of submodules [1],

Cheers,

[1]  http://git-scm.com/book/en/Git-Tools-Submodules

-- Forwarded message --
From: jlboud...@apache.org
Date: 2014-06-12 18:46 GMT+02:00
Subject: git commit: Add xooki as submodule
To: notificati...@ant.apache.org


Repository: ant-ivy
Updated Branches:
  refs/heads/master eb1ee360d - 30df10074


Add xooki as submodule


Project: http://git-wip-us.apache.org/repos/asf/ant-ivy/repo
Commit: http://git-wip-us.apache.org/repos/asf/ant-ivy/commit/30df1007
Tree: http://git-wip-us.apache.org/repos/asf/ant-ivy/tree/30df1007
Diff: http://git-wip-us.apache.org/repos/asf/ant-ivy/diff/30df1007

Branch: refs/heads/master
Commit: 30df1007424921749d00ca922bfdecdac187918f
Parents: eb1ee36
Author: Jean-Louis Boudart jeanlouis.boud...@gmail.com
Authored: Thu Jun 12 18:46:35 2014 +0200
Committer: Jean-Louis Boudart jeanlouis.boud...@gmail.com
Committed: Thu Jun 12 18:46:35 2014 +0200

--
 .gitmodules | 3 +++
 doc/xooki   | 1 +
 2 files changed, 4 insertions(+)
--


http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/30df1007/.gitmodules
--
diff --git a/.gitmodules b/.gitmodules
new file mode 100644
index 000..d8b91df
--- /dev/null
+++ b/.gitmodules
@@ -0,0 +1,3 @@
+[submodule doc/xooki]
+   path = doc/xooki
+   url = git://git.apache.org/ant-xooki.git

http://git-wip-us.apache.org/repos/asf/ant-ivy/blob/30df1007/doc/xooki
--
diff --git a/doc/xooki b/doc/xooki
new file mode 16
index 000..38eff00
--- /dev/null
+++ b/doc/xooki
@@ -0,0 +1 @@
+Subproject commit 38eff00e65ec74803838b52a111cab542cb80bca




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


Re: [jira] [Commented] (INFRA-7816) Create readonly git mirror for Xooki

2014-06-11 Thread Jean-Louis Boudart
This impacts all svn:external :/ could we limit on ivy web site,core trunk
ans current branch ?
Le 11 juin 2014 10:00, Nicolas Lalevée nicolas.lale...@hibnet.org a
écrit :


 Le 10 juin 2014 à 21:29, Jan Matèrne (jhm) apa...@materne.de a écrit :

  I wouldnt count myself to the Ivy team, but I prefer changing to
 trunk/branches structure:
  * conform to other svn repos
  * easier setup for infra for the read only git repo

 +1

 Nicolas


 
  Jan
 
  -Ursprüngliche Nachricht-
  Von: Jean-Louis Boudart [mailto:jeanlouis.boud...@gmail.com]
  Gesendet: Dienstag, 10. Juni 2014 20:59
  An: Ant Developers List
  Betreff: Fwd: [jira] [Commented] (INFRA-7816) Create readonly git
  mirror for Xooki
 
  Some updates about creation of xooki git mirror.
 
  @Ivy team any opinions ?
 
  -- Forwarded message --
  From: #asfinfra IRC Bot (JIRA) j...@apache.org
  Date: 2014-06-10 20:51 GMT+02:00
  Subject: [jira] [Commented] (INFRA-7816) Create readonly git mirror for
  Xooki
  To: jeanlouis.boud...@gmail.com
 
 
 
 [
  https://issues.apache.org/jira/browse/INFRA-
  7816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
  tabpanelfocusedCommentId=14026838#comment-14026838
  ]
 
  #asfinfra IRC Bot commented on INFRA-7816:
  --
 
  Humbedooh The import script is fine, but we cannot import Xooki as it
  is currently laid out due to lack of a trunk/branches structure, so
  this will either take a while longer or you will have to change the svn
  to reflect this structure
 
 
  Create readonly git mirror for Xooki
  -
 
 Key: INFRA-7816
 URL: https://issues.apache.org/jira/browse/INFRA-7816
 Project: Infrastructure
  Issue Type: Task
  Components: Git
Reporter: Jean-Louis Boudart
 
  Could you please create a readonly git mirror of xooki (
  https://svn.apache.org/repos/asf/ant/site/xooki/) ?
  Xooki is a documentation tool used by :
  * Ivy
  * IvyDE
  * EasyAnt
  Those projects were migrated to git recently as part of ant family
  migration to git (INFRA-7759).
  We use xooki for both project documentation and official website.
  Xooki should remains in svn to make website generation, but we need a
  readonly git mirror that will be used as git submodule for project
  documentation.
  Thanks in advance.
 
 
 
  --
  This message was sent by Atlassian JIRA
  (v6.2#6252)
 
 
 
  --
  Jean Louis Boudart
  Independent consultant
  Apache EasyAnt commiter http://ant.apache.org/easyant/
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




Re: [jira] [Commented] (INFRA-7816) Create readonly git mirror for Xooki

2014-06-11 Thread Jean-Louis Boudart
I just received a notification from INFRA team. Xooki readonly git mirror
is available :).

2014-06-11 10:51 GMT+02:00 Nicolas Lalevée nicolas.lale...@hibnet.org:

 You worry about the svn:externals in the tags of Ivy and alter ? These
 externals are supposed to be fixed to a svn revision, so nothing to change
 there.

 Nicolas

 Le 11 juin 2014 à 10:12, Jean-Louis Boudart jeanlouis.boud...@gmail.com
 a écrit :

  This impacts all svn:external :/ could we limit on ivy web site,core
 trunk
  ans current branch ?
  Le 11 juin 2014 10:00, Nicolas Lalevée nicolas.lale...@hibnet.org a
  écrit :
 
 
  Le 10 juin 2014 à 21:29, Jan Matèrne (jhm) apa...@materne.de a écrit
 :
 
  I wouldnt count myself to the Ivy team, but I prefer changing to
  trunk/branches structure:
  * conform to other svn repos
  * easier setup for infra for the read only git repo
 
  +1
 
  Nicolas
 
 
 
  Jan
 
  -Ursprüngliche Nachricht-
  Von: Jean-Louis Boudart [mailto:jeanlouis.boud...@gmail.com]
  Gesendet: Dienstag, 10. Juni 2014 20:59
  An: Ant Developers List
  Betreff: Fwd: [jira] [Commented] (INFRA-7816) Create readonly git
  mirror for Xooki
 
  Some updates about creation of xooki git mirror.
 
  @Ivy team any opinions ?
 
  -- Forwarded message --
  From: #asfinfra IRC Bot (JIRA) j...@apache.org
  Date: 2014-06-10 20:51 GMT+02:00
  Subject: [jira] [Commented] (INFRA-7816) Create readonly git mirror
 for
  Xooki
  To: jeanlouis.boud...@gmail.com
 
 
 
[
  https://issues.apache.org/jira/browse/INFRA-
  7816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
  tabpanelfocusedCommentId=14026838#comment-14026838
  ]
 
  #asfinfra IRC Bot commented on INFRA-7816:
  --
 
  Humbedooh The import script is fine, but we cannot import Xooki as
 it
  is currently laid out due to lack of a trunk/branches structure, so
  this will either take a while longer or you will have to change the
 svn
  to reflect this structure
 
 
  Create readonly git mirror for Xooki
  -
 
Key: INFRA-7816
URL: https://issues.apache.org/jira/browse/INFRA-7816
Project: Infrastructure
 Issue Type: Task
 Components: Git
   Reporter: Jean-Louis Boudart
 
  Could you please create a readonly git mirror of xooki (
  https://svn.apache.org/repos/asf/ant/site/xooki/) ?
  Xooki is a documentation tool used by :
  * Ivy
  * IvyDE
  * EasyAnt
  Those projects were migrated to git recently as part of ant family
  migration to git (INFRA-7759).
  We use xooki for both project documentation and official website.
  Xooki should remains in svn to make website generation, but we need a
  readonly git mirror that will be used as git submodule for project
  documentation.
  Thanks in advance.
 
 
 
  --
  This message was sent by Atlassian JIRA
  (v6.2#6252)
 
 
 
  --
  Jean Louis Boudart
  Independent consultant
  Apache EasyAnt commiter http://ant.apache.org/easyant/
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: AW: Repository access

2014-06-10 Thread Jean-Louis Boudart
I just opened a new infra ticket as easyant is no longer in incubation.
https://issues.apache.org/jira/browse/INFRA-7890


2014-06-08 11:20 GMT+02:00 Jan Matèrne (jhm) apa...@materne.de:

 Ticket closed:
 gmcdonald the asf-authorization-template is the place to add folks to
 easyant incubator project. A PMC Chair can do this. If EasyAnt is no longer
 an Incubator project then this auth needs to be removed and merged with
 Ant. As a subproject of Ant all the git repos would need to be renamed to
 be pre-pended with Ant- for auth to work - in the same way as taglibs and
 Ivy are done now. Open an issue to have those repos renamed


 Next step by Conor ...


 Jan



  -Ursprüngliche Nachricht-
  Von: Jan Matèrne (jhm) [mailto:apa...@materne.de]
  Gesendet: Samstag, 7. Juni 2014 12:15
  An: 'Ant Developers List'
  Betreff: AW: AW: Repository access
 
  My personal test: write access to all ant-* repos, but no easyant-*
  repos.
  Maybe because I wasn't involved in the incubation phase?
 
  I opened https://issues.apache.org/jira/browse/INFRA-7877
 
 
  Jan
 
   -Ursprüngliche Nachricht-
   Von: Antoine Levy-Lambert [mailto:anto...@gmx.de]
   Gesendet: Freitag, 6. Juni 2014 18:20
   An: dev@ant.apache.org
   Betreff: Re: AW: Repository access
  
   I do not think each commiter needs to do that but if you and
   Jean-Louis go through this exercise and create an INFRA ticket that
   would be very nice. As for me I have a lot of work in my day job and
   on top of that I have caught an out of season cold, with the
   temperature in New York going up and down and too much air
  conditioning at some places.
  
   Regards,
  
   Antoine
  
   Le 6 juin 2014 01:08, =?ISO-8859-1?Q?Jan_Mat=E8rne_=28jhm=29?=
   apa...@materne.de a écrit :
   
Should we (each committer) try to commit/push to each repo before
creating the issue?
Maybe creating one file/repo (./git-access-test) where each
committer places his name.
Retest after the issue is resolved and finally delete that file.
   
In that way INFRA doesnt need to act multiple times ...
   
Jan
   
 -Ursprüngliche Nachricht-
 Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
 Gesendet: Freitag, 6. Juni 2014 03:21
 An: Ant Developers List
 Betreff: Re: Repository access

 Hello Jean-Louis,

 please create the JIRA,

 Antoine
 On Jun 5, 2014, at 3:03 PM, Jean-Louis Boudart
 jeanlouis.boud...@gmail.com wrote:

  Same for me is there other repos having same issue?
 
  We need to create a INFRA jira for this.
 
 
  2014-06-05 18:08 GMT+02:00 Nicolas Lalevée
 nicolas.lale...@hibnet.org:
 
  I couldn't commit the patch you suggested for the ivyde
  updatesite
 in
  svn either. It must be read only.
 
  Nicolas
 
  Le 5 juin 2014 à 07:57, Jan Matèrne (jhm) apa...@materne.de
  a
 écrit :
 
  After ivyde-updatesite (svn) this is the 2nd repo where I
  can't
  commit/push
 
  https://git-wip-us.apache.org/repos/asf/easyant-core.git
 
 
 
  Is there any reason?
 
 
 
 
 
  Jan
 
 
 
  --
  -
  -
   -
  ---
 -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
 additional
  commands, e-mail: dev-h...@ant.apache.org
 
 
 
 
  --
  Jean Louis Boudart
  Independent consultant
  Apache EasyAnt commiter http://ant.apache.org/easyant/


 -
  -
 -
   -
 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
 additional commands, e-mail: dev-h...@ant.apache.org
   
   
   
---
  -
- To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
additional commands, e-mail: dev-h...@ant.apache.org
   
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
   commands, e-mail: dev-h...@ant.apache.org
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
  commands, e-mail: dev-h...@ant.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Fwd: [jira] [Commented] (INFRA-7816) Create readonly git mirror for Xooki

2014-06-10 Thread Jean-Louis Boudart
Some updates about creation of xooki git mirror.

@Ivy team any opinions ?

-- Forwarded message --
From: #asfinfra IRC Bot (JIRA) j...@apache.org
Date: 2014-06-10 20:51 GMT+02:00
Subject: [jira] [Commented] (INFRA-7816) Create readonly git mirror for
Xooki
To: jeanlouis.boud...@gmail.com



[
https://issues.apache.org/jira/browse/INFRA-7816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14026838#comment-14026838
]

#asfinfra IRC Bot commented on INFRA-7816:
--

Humbedooh The import script is fine, but we cannot import Xooki as it is
currently laid out due to lack of a trunk/branches structure, so this will
either take a while longer or you will have to change the svn to reflect
this structure


 Create readonly git mirror for Xooki
 -

 Key: INFRA-7816
 URL: https://issues.apache.org/jira/browse/INFRA-7816
 Project: Infrastructure
  Issue Type: Task
  Components: Git
Reporter: Jean-Louis Boudart

 Could you please create a readonly git mirror of xooki (
https://svn.apache.org/repos/asf/ant/site/xooki/) ?
 Xooki is a documentation tool used by :
  * Ivy
  * IvyDE
  * EasyAnt
 Those projects were migrated to git recently as part of ant family
migration to git (INFRA-7759).
 We use xooki for both project documentation and official website.
 Xooki should remains in svn to make website generation, but we need a
readonly git mirror that will be used as git submodule for project
documentation.
  Thanks in advance.



--
This message was sent by Atlassian JIRA
(v6.2#6252)



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


Re: GitHub integration

2014-06-07 Thread Jean-Louis Boudart
+1
Le 7 juin 2014 12:21, Jan Matèrne (jhm) apa...@materne.de a écrit :


 https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
 To be more precise, these new features allows for the following:

 1. Any Pull Request that gets opened, closed, reopened or commented on now
 gets recorded on the project's mailing list
 2. If a project has a JIRA instance, any PRs or comments on PRs that
 include
 a JIRA ticket ID will trigger an update on that specific ticket
 3. Replying to a GitHub comment on the dev@ mailing list will trigger a
 comment being placed on GitHub (yes, it works both ways!)
 4. GitHub activity can now be relayed to IRC channels on the Freenode
 network.

 As with most of our things, this is an opt-in feature.



 I suggest adding GitHub-support#1 and #3.
 #2 could be interesting für EasyAnt and Ivy, as they are using JIRA (Ant
 uses Bugzilla).
 Not sure about #4. What's the activity on freenode?


 Jan


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




Re: EasyAnt - status

2014-06-05 Thread Jean-Louis Boudart
Good catch unfortunatly like you i have no commit access there :/


2014-06-05 8:15 GMT+02:00 Jan Matèrne (jhm) apa...@materne.de:

 In easyant-core there are two disclaimers (DISCLAIMER, README) saying that
 EA is still in incubation.

 I thought i was graduated ... this was also posted on
 http://blog.easyant.org/apache-graduation/

 This should be updated.



 Jan




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


Re: Repository access

2014-06-05 Thread Jean-Louis Boudart
Same for me is there other repos having same issue?

We need to create a INFRA jira for this.


2014-06-05 18:08 GMT+02:00 Nicolas Lalevée nicolas.lale...@hibnet.org:

 I couldn't commit the patch you suggested for the ivyde updatesite in svn
 either. It must be read only.

 Nicolas

 Le 5 juin 2014 à 07:57, Jan Matèrne (jhm) apa...@materne.de a écrit :

  After ivyde-updatesite (svn) this is the 2nd repo where I can't
 commit/push
 
  https://git-wip-us.apache.org/repos/asf/easyant-core.git
 
 
 
  Is there any reason?
 
 
 
 
 
  Jan
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: migration to git : next steps

2014-05-27 Thread Jean-Louis Boudart
I just filled an jira ticket for this :
https://issues.apache.org/jira/browse/INFRA-7816


2014-05-27 4:42 GMT+02:00 Antoine Levy Lambert anto...@gmx.de:

 Hello Jean Louis,

 if you have some cycles for that, you can join infra on IRC ( #asfinfra )
 and ask to see whether someone has an idea.



 Antoine


 On May 26, 2014, at 9:51 PM, Jean-Louis Boudart 
 jeanlouis.boud...@gmail.com wrote:

  The only broken stuff is easyant / ivy documentations as we were using
  lot of svn:externals (to retrieve latest xooki version for example).
  svn:externals are not migrated so we need to find a solution for this.
 
 
 
 
  2014-05-25 20:55 GMT+02:00 Stefan Bodewig bode...@apache.org:
 
  On 2014-05-23, anto...@gmx.de wrote:
 
  Jake Farrell has finished the migration, we are asked to verify. Right
  now I am at work so cannot verify but will look during the weekend.
 
  I had a quick look at Ant core, seems to work reasonably.
 
  One thing though, the github mirror is now trying to track the no longer
  existing tunk branch rather than the new master branch.
 
  Stefan
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 
  --
  Jean Louis Boudart
  Independent consultant
  Apache EasyAnt commiter http://ant.apache.org/easyant/


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: migration to git : next steps

2014-05-26 Thread Jean-Louis Boudart
The only broken stuff is easyant / ivy documentations as we were using
lot of svn:externals (to retrieve latest xooki version for example).
svn:externals are not migrated so we need to find a solution for this.




2014-05-25 20:55 GMT+02:00 Stefan Bodewig bode...@apache.org:

 On 2014-05-23, anto...@gmx.de wrote:

  Jake Farrell has finished the migration, we are asked to verify. Right
  now I am at work so cannot verify but will look during the weekend.

 I had a quick look at Ant core, seems to work reasonably.

 One thing though, the github mirror is now trying to track the no longer
 existing tunk branch rather than the new master branch.

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: migration to git : next steps

2014-05-24 Thread Jean-Louis Boudart
As far as i can tell everything seems ok.

I have checked :
 * ant
 * ivy
 * antunit
 * every easyant-* repo

All branches / tags are there with latest commits.



2014-05-23 19:49 GMT+02:00 anto...@gmx.de anto...@gmx.de:

 Jake Farrell has finished the migration, we are asked to verify. Right now
 I am at work so cannot verify but will look during the weekend.

 See
 https://issues.apache.org/jira/plugins/servlet/mobile#issue/INFRA-7759

 Antoine Levy-Lambert

 - Reply message -
 From: Antoine Levy Lambert anto...@gmx.de
 To: Ant Developers List dev@ant.apache.org
 Subject: migration to git : next steps
 Date: Thu, May 22, 2014 10:17 PM

 Hi,

 moving to actual action.

 jfarrell from infra is setting our svn repo
 http://svn.apache.org/repos/asf/ant read-only to prepare for the import.

 The ant site will remain in svn and stay RW during the process.

 Antoine

 On May 20, 2014, at 10:25 PM, Matt Sicker boa...@gmail.com wrote:

  I'm going to have to look into subtree as I've been using submodule at
 work
  lately and it's becoming a huge mess.
 
 
  On 20 May 2014 13:39, Charles Duffy char...@dyfis.net wrote:
 
  I'd suggest looking into git-subtree as well, if we wanted to maintain a
  single-development-tree experience. Submodules have a reputation
  (well-deserved, IMHO) of being somewhat unwieldy to work with; using
  git-subtree to manage linked trees can be a bit more automation/setup
 work,
  but can also provide a much smoother user experience.
 
 
  On Mon, May 12, 2014 at 8:03 PM, Matt Sicker boa...@gmail.com wrote:
 
  Something I've been experimenting with is using git submodules. You
  basically have a repository for each submodule, then you can have
  another
  repository that groups them all together for convenience. It's handy
 for
  making a sort of stable master that points to the latest tag or
 something
  similar. It's kind of confusing, but I think it works well for when
  people
  want to check out a project corresponding to the latest stable rather
  than
  the trunk (which would normally be stable anyway).
 
 
  On 12 May 2014 21:19, Antoine Levy Lambert anto...@gmx.de wrote:
 
 
  Hi,
 
  resending a message which I sent on May 7th but might have been lost
  completely due to our infrastructure problems last week :
 
 
 
  To actually migrate to git, we could either make one INFRA JIRA for
  all
  the ant family of projects, or do this one step at a time.
 
  Concerning the antlibs, I suppose we want one git module for each
  antlib
  - we have 6 of them (antunit, compress, dotnet, props, svn, vss) plus
 a
  common folder which ought to be on its own.
 
  If we do it one step at a time we could start with ant proper, then
  move
  to ivy, ivyde, easyant and the antlibs.
 
  What do you think ?
 
  Antoine
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 
 
 
  --
  Matt Sicker boa...@gmail.com
 
 
 
 
 
  --
  Matt Sicker boa...@gmail.com




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


Re: Ivy's ModuleDescriptor.getExtraInfo() is now deprecated

2014-05-11 Thread Jean-Louis Boudart
Hi Nicolas,

This was introduced by IVY-1457 and breaks backward compatibility as
mentioned there. All call to old api from ivy-core itslef has been migrated
on trunk. I didn't find any elegant way to make it backward compatible.
Suggestion are welcome.

But yeah basically you get the idea :/


2014-05-11 17:07 GMT+02:00 Nicolas Lalevée nicolas.lale...@hibnet.org:

 Hi,

 ModuleDescriptor.getExtraInfo() is deprecated but there is no indication
 in the doc about what should be used then. There is getExtraInfos(), but as
 I look to the code, there is no data transfer between both, if if there is
 data in one, I cannot get the data from the other one. And since the
 XmlModuleDescriptorWriter is only handling ExtraInfoHolder, some data are
 lost.

 For this new need method getExtraInfos() to work properly, I guess it have
 to handle all the calls to the deprecated getExtraInfo(). Am I missing
 something ?

 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Release Ant 1.9.4 (second attempt)

2014-05-05 Thread Jean-Louis Boudart
+1
tested with easyant without any issue


2014-04-30 5:46 GMT+02:00 Antoine Levy Lambert anto...@gmx.de:

 Hi all,

 restarting the vote thread after having fixed the pom of ant-testutil and
 rebuilt

 a release with many bug fixes and improvements, including the initial
 support for Java 1.9,
 the possibility to run JUnit tests in multiple threads (when they are
 forked)
 and the refactoring of Ant's own test suite which is now based on JUnit 4.

 I propose to adopt the following as Ant 1.9.4

 SVN tag: http://svn.apache.org/repos/asf/ant/core/tags/ANT_194/
   revision 1591180
 Tarballs: https://dist.apache.org/repos/dist/dev/ant/
   revision 5204
 Maven Artifacts:

 https://repository.apache.org/content/repositories/orgapacheant-1004/org/apache/ant/

 Vote will be open until Monday, May 5 due to upcoming May 1st holiday

 Cheers

 Antoine




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


Re: migration to git and web site publication

2014-04-29 Thread Jean-Louis Boudart
Then this could be an issue with while migrating to git for Ivy / EasyAnt
as they both use xooki to create website and project documentation (website
contains version of each releassed documentation through svn:external).

I thought gitpubsub could be used for website.


2014-04-29 5:00 GMT+02:00 Antoine Levy Lambert anto...@gmx.de:

 Hello Jan,

 On Apr 28, 2014, at 1:29 AM, Jan Matèrne (jhm) apa...@materne.de wrote:

 
 
 
  The web sites will remain in svn in any event because svnpubsub is the
  only supported mechanism to maintain web sites AFAIK.
 
  I havent looked at the current svnpubsub, but there is also one with that
  name for git
  https://www.apache.org/dev/gitpubsub.html
 
  I would appreciate to have the same scm.
  Could we start a new git repo for tests and vote later after the
  git/gitpubsub is working?

  Apache Infra does not support gitpubsub for the purpose of maintaining an
 Apache web site.
 I asked confirmation of that on the #asfinfra
 All Apache web sites are in svn and use svnpubsub.
 git is not the tool of choice to deal with large files such as the ones on
 dist.apache.org.
 That might be part of the reason why infra supports only svn for the web
 site.

 
 
  Jan
 
 
 Antoine


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] migration to git

2014-04-28 Thread Jean-Louis Boudart
2014-04-28 5:02 GMT+02:00 Antoine Levy Lambert anto...@gmx.de:

 Hi,

 Let's vote about migrating to git :

 -  Ant

 - Ivy

 - easyant

 - Ivyde

 - the antlibs

 I am not including the sandbox in the thread intentionally.

 The web sites will remain in svn in any event because svnpubsub is the
 only supported mechanism to maintain web sites AFAIK.

 [] Yes
 [] No


+1 on all :)


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


Re: Migration of Ant test to JUnit4

2014-04-14 Thread Jean-Louis Boudart
Great job !


2014-04-12 15:37 GMT+02:00 Michael Clarke michael.m.cla...@gmail.com:

 Hi,

 I've now completed the migration of Ant's test cases to JUnit4 and would
 like to give other developers a chance to review/comment on these changes
 before I merge them back into SVN. My changes can be found on Github at
 https://github.com/mc1arke/ant/tree/JUnit4Conversion (
 https://github.com/mc1arke/ant/compare/JUnit4Conversion.patch for anyone
 who wants to apply a patch against their local workspace).

 Notable changes:
 1. Deprecation of org.apache.tools.ant.BuildFileTest
 and org.apache.tools.ant.types.selectors.BaseSelectorTest
 2. Introduction of org.apache.tools.ant.BuildFileRule and
 org.apache.tools.ant.types.selectors.BaseSelectorRule to replace deprecated
 classes, but with the removal of methods directly relating to asserting
 values
 3. Introduction of org.apache.tools.ant.AntAssert to provide additional
 Asserts beyond the default JUnit ones, and thecreation of
 org.apache.tools.ant.FileUtilities to provide common file utilities used in
 many tests
 4. Addition of @Test annotation to all Test methods, and addition or
 @Ignore annotations to methods that had previously been commented out or
 named in a way that prevented JUnit 3 seeing/running them.
 5. Use of JUnit's Assume to dynamically skip tests that previously silently
 returned if certain conditions weren't met (e.g. the Symlink tests not
 running on Windows)
 6. TODO markers added to tests that previously used exception handling
 checks but didn't check the value of the exception being returned. I'll
 look at coming back to these in the future to add proper asserts and remove
 the TODOs.
 7. Removal of Thread.sleep in tests, and the sleep command in associated
 XML build files where this has been used to force a difference in file
 creation timestamps, and the use of File.setLastModified() instead. This
 has knocked 1 minute 30 seconds off the JUnit execution time using
 Cloudbees Buildhive Jenkins instance, although I've not looked at whether
 similar can be done for the AntUnit tests.
 8. Updated the documentation for writing tests to refer to the new 'Rule'
 classes rather than the previous Test classes

 I'll hold of committing these changes to SVN for a couple of days to give
 people a chance to comment. Unless I hear any significant objections to
 these changes by the middle of Wednesday, I'll look commit to SVN on
 Wednesday night (UK time).

 Thanks,
 Michael




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


Migrating to Git

2014-04-14 Thread Jean-Louis Boudart
HI there,

Since write git repository are accessible for a while, i suggest (as many
of you) to switch projects to git.
I know this has been discussed many times [1] but never in a dedicated
thread.

So what do you think about this ?

Are you ok to migrate :
 * ant
 * ivy / ivyde
 * easyant
 * rest of stuff (antlibs, stuff from sandbox?)


[1] http://markmail.org/message/6ik4nyueayz2fpnx
-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/


Re: Migrating to Git

2014-04-14 Thread Jean-Louis Boudart
2014-04-14 11:59 GMT+02:00 Nicolas Lalevée nicolas.lale...@hibnet.org:

 I like git, so I like the idea.

 But what about the publication of the doc on the website ? Today we rely
 on svn:externals for the doc of each release. How would it be managed if
 it's migrated to git ?

I think this could be solved with git submodules [1] for example and then
triggered by gitpubsub [2].



 And I have not searched in the ASF docs, but do you have any pointer on
 some guidelines about handling IP ? Can we merge any pull request ?

Don't have any pointer about handling IP but i'm sure people invested in
other Apache project present in this ML could give us their guidelines.



[1] http://git-scm.com/book/en/Git-Tools-Submodules
[2] https://www.apache.org/dev/gitpubsub.html


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


Re: [VOTE] Apache Ivy 2.4.0-rc1 Release

2014-03-17 Thread Jean-Louis Boudart
+1
Le 15 mars 2014 23:18, Maarten Coene maarten_co...@yahoo.com a écrit :

 Hi all,

 I have built Apache Ivy 2.4.0-rc1.

 Here are the links:
 SVN tag: https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.4.0-rc1/
 Binaries: https://dist.apache.org/repos/dist/dev/ant/ivy/2.4.0-rc1
 Maven repository:
 https://repository.apache.org/content/repositories/orgapacheant-1002/

 Do you vote for the release of these binaries?

 [ ] Yes
 [ ] No

 Kind regards,
 Maarten Coene


Re: [VOTE] Ivy 2.4.0-rc1 Release

2014-02-13 Thread Jean-Louis Boudart
Is the release over ?

I dont find it on maven central
Le 28 janv. 2014 01:46, Charles Duffy char...@dyfis.net a écrit :

 The keys are actually different -- the one used by the currently-posted
 .asc files is associated with Indeed, Inc. I'll be resigning the binaries
 after verifying that their Indeed signatures are intact (and moving them to
 dist.apache.org at that time).

 Expect a note in this thread when that happens.


 On Mon, Jan 27, 2014 at 6:42 PM, Nicolas Lalevée 
 nicolas.lale...@hibnet.org
  wrote:

 
  Le 22 janv. 2014 à 00:52, Nicolas Lalevée nicolas.lale...@hibnet.org a
  écrit :
 
   I have found some issues. The source distribution seems to miss some
  test files. I guess this has been the case for quite some time. And it is
  just about the tests. And it is an RC. So OK for me. And I will fix
 that
  soon in trunk.
  
   To avoid confusion and make things simpler, I suggest we modify the
  release process to that everything goes through the svn of
 dist.apache.org,
  and not use anymore people.apache.org. In the end, everything is
  published there.
   And I'll modify in the doc of the release process the template of the
  email of the vote to include a line that is referencing the svn tag. So
  it's more difficult to miss it, and it is helpful to do review.
  
   I have tested the staging update site: works like a charm.
  
   So LGTM.
  
   I will cast my vote as soon as I can verify the signature of the
  artifacts.
 
  You pushed some keys to the KEYS files, but it doesn't seems to be the
  same as the one you used to sign the proposed artifacts.
 
  My gpg is asking for the key ID 93FB868A. Did I do something wrong or the
  keys are actually different ?
 
  Nicolas
 
 
  
   Nicolas
  
   Le 21 janv. 2014 à 17:19, Charles Duffy char...@dyfis.net a écrit :
  
   FYI --
  
   A tag at
 https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.4.0-rc1now
   exists. This differs from the branch head from which the binaries for
  test
   were built only inasmuch as its svn:externals specify a specific
  revision
   of the documentation build tools rather than leaving their revision
   floating.
  
  
   On Tue, Jan 21, 2014 at 6:54 AM, Charles Duffy char...@dyfis.net
  wrote:
  
   Howdy --
  
   I've attempted to follow the documentation at
   http://ant.apache.org/ivy/history/trunk/dev/makerelease.html and
   http://ant.apache.org/ivy/ivyde/history/trunk/dev/updatesite.html(as
   included-by-reference in the former) in preparing the above. That
  said, it
   appears that I missed step 12 (and, accordingly, have a 1.4.0-rc1
  branch,
   from the present tip of which the binaries were built, but no
  associated
   tag).
  
   I'll be sure to get KEYS up-to-date. Thank you for the pointers.
  
  
   On Tue, Jan 21, 2014 at 6:26 AM, Stefan Bodewig bode...@apache.org
  wrote:
  
   Hi Charles,
  
   we don't really release binaries, they are just a convenience.  All
  that
   matters as a release is the sources.
  
   I'm not sure there is anything documenting the release process for
 Ivy
   but in general you create an svn tag and build source and binary
   distributions from that.
  
   What you have built now is a binary for testing and you don't really
   need to vote on that at all.  Just encourage people to try it out
 :-)
  
   If you want to perform some sort of test-release, have a look at
   http://svn.apache.org/repos/asf/ant/antlibs/ReleaseInstructions
 and
   similar instructions to get an idea of what is expected.
  
   PS -- As this build was performed on hardware owned by Indeed,
 Inc.,
  the
   binaries are signed with the du...@indeed.com GPG key. For any
 final
   release, I would be using hardware under personal control and a key
   associated with cdu...@apache.org.
  
   Please make sure whatever key you use is inside
   https://dist.apache.org/repos/dist/release/ant/KEYS - if you need
 any
   help committing it there, please yell.
  
   Cheers
  
 Stefan
  
  
 -
   To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
   For additional commands, e-mail: dev-h...@ant.apache.org
  
  
  
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
   For additional commands, e-mail: dev-h...@ant.apache.org
  
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 



Re: [VOTE] Ivy 2.4.0-rc1 Release

2014-01-22 Thread Jean-Louis Boudart
+1


2014/1/21 Per Arnold Blaasmo per-arnold.blaa...@atmel.com

 +1


 On 20. jan. 2014 19:19, Charles Duffy wrote:
  I have built a release candidate for Ivy 2.4.0.
 
  You can download it from this URL:
  http://people.apache.org/~cduffy/ivy-2.4.0-rc1/
 
  Do you vote for the release of these binaries?
 
  [ ] Yes
  [ ] No
 
  Regards,
 
  Charles Duffy, Ivy 2.4.0 release manager
 
 
  PS -- As this build was performed on hardware owned by Indeed, Inc., the
  binaries are signed with the du...@indeed.com GPG key. For any final
  release, I would be using hardware under personal control and a key
  associated with cdu...@apache.org.
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Release Compress Antlib 1.4 Based on RC1

2014-01-22 Thread Jean-Louis Boudart
+1

Is it normal that tag name is 1.4_RC1 but not in the maven version or name
in dist.apache.org ?


2014/1/21 Stefan Bodewig bode...@apache.org

 Hi all,

 following the Commons Compress 1.7 release I'd like to release a new
 version of the Antlib as well.  Most importantly this adds tasks and
 resources for Snappy and traditional Unix .Z compress.  Both of them
 read-only.

 svn tag:
 https://svn.apache.org/repos/asf/ant/antlibs/compress/tags/1_4_RC1/
 (svn revision 1559922)

 Tarballs:
 https://dist.apache.org/repos/dist/dev/ant/antlibs/compress/
 (svn revision 4125)

 Maven Central Stuff:

 https://repository.apache.org/content/repositories/orgapacheant-1001/org/apache/ant/ant-compress/1.4/

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Release Compress Antlib 1.4 Based on RC1

2014-01-22 Thread Jean-Louis Boudart
Fine :)


2014/1/22 Stefan Bodewig bode...@apache.org

 On 2014-01-22, Jean-Louis Boudart wrote:

  +1

  Is it normal that tag name is 1.4_RC1 but not in the maven version or
 name
  in dist.apache.org ?

 This vote is not about a RC but I have created an RC and the vote is
 about calling that 1.4 - final, if you will.

 If the vote passes, I'll copy the tag and not create any new artifacts.

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


ModuleDescriptorParser used in RepositoryCacheManager and ResolutionCacheManager

2014-01-14 Thread Jean-Louis Boudart
Hi there,

Currently, the ModuleDescriptorParser used in both  RepositoryCacheManager
and ResolutionCacheManager is hardcoded as XmlModuleDescriptorParser.

I'm wondering if this make sense to be hardcoded ?

Wouldn't be better to use
ModuleDescriptorParserRegistry.getInstance().getParser() ? Or at least
extract the hardcoded MDParser in a method to get easily changed by
subclasses ?



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


Re: Ivy Code formatting

2014-01-14 Thread Jean-Louis Boudart
Done on trunk :)


2014/1/13 Charles Duffy char...@dyfis.net

 Oops!

 My apologies for having forgotten this was pending when cutting the -rc1
 branch. Happy to update the branch after this change is in, before tagging
 and building something to formally propose for voting.


 On Sun, Jan 12, 2014 at 11:14 AM, Jean-Louis Boudart 
 jeanlouis.boud...@gmail.com wrote:

  Hi there,
 
  While fixing a bug i noticed that ivy source code was not fully
 formatted.
  Eclipse formatter is not exported as a plain file but present through
  eclipse project preferences in .settings folder [1].
 
  Considering .settings folder is already commited i suggest to activate
  Saved actions to apply on each save :
 
 - code formatting
 - organize import
 
 
  I also suggest to apply formatting on whole project (could be done in a
 few
  clicks with cleanup feature in eclipse).
 
  Are you in favor of those code modifications ?
 
  We could take the opportunity to cut this before 2.4.0 release.
 
  PS: This could aslo applied on others subprojects (ant for example)
 
  [1]
 
 
 https://svn.apache.org/repos/asf/ant/ivy/core/trunk/.settings/org.eclipse.jdt.core.prefs
 
  --
  Jean Louis Boudart
  Independent consultant
  Apache EasyAnt commiter http://ant.apache.org/easyant/
 




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


Ivy Code formatting

2014-01-12 Thread Jean-Louis Boudart
Hi there,

While fixing a bug i noticed that ivy source code was not fully formatted.
Eclipse formatter is not exported as a plain file but present through
eclipse project preferences in .settings folder [1].

Considering .settings folder is already commited i suggest to activate
Saved actions to apply on each save :

   - code formatting
   - organize import


I also suggest to apply formatting on whole project (could be done in a few
clicks with cleanup feature in eclipse).

Are you in favor of those code modifications ?

We could take the opportunity to cut this before 2.4.0 release.

PS: This could aslo applied on others subprojects (ant for example)

[1]
https://svn.apache.org/repos/asf/ant/ivy/core/trunk/.settings/org.eclipse.jdt.core.prefs

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


Re: [VOTE] Release Ant 1.9.3

2013-12-23 Thread Jean-Louis Boudart
+1
Le 23 déc. 2013 17:42, Antoine Levy Lambert anto...@gmx.de a écrit :

 Hi all,

 a small release with some bug fixes particularly the fix for the bug 54128
 exec task changes have slowed exec to a crawl

 I propose to adopt the following as Ant 1.9.3

 SVN tag: http://svn.apache.org/repos/asf/ant/core/tags/ANT_193/
revision 1553123
 Tarballs: https://dist.apache.org/repos/dist/dev/ant/
revision 3969
 Maven Artifacts:

 https://repository.apache.org/content/repositories/orgapacheant-015/org/apache/ant/

 Vote will be open for about 96 hours due to the holiday this week

 Cheers

Antoine



Re: [RESULT][VOTE] Jean-Louis Boudart as a PMC member

2013-12-03 Thread Jean-Louis Boudart
Thanks guys !




2013/12/3 Nicolas Lalevée nicolas.lale...@hibnet.org

 I count 7 binding +1. The vote pass.

 Welcome to the Ant PMC Jean-Louis !

 Nicolas

 Le 26 nov. 2013 à 12:04, Nicolas Lalevée nicolas.lale...@hibnet.org a
 écrit :

  Jean-Louis has been around for a very long time, owned committership,
 contributed a lot to bring EasyAnt into the Ant PMC, and he is
 participating to the vote in the release process.
 
  Thus, let's invite Jean-Louis to be part of the PMC.
 
  Here is my +1.
 
  Nicolas
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Charles Duffy as a committer

2013-11-24 Thread Jean-Louis Boudart
+1


2013/11/23 Stefan Bodewig bode...@apache.org

 On 2013-11-22, Antoine Levy-Lambert wrote:

  I would like to nominate Charles Duffy as a committer. Charles has
  proposed a number of patches to Ivy such as IVY-1421, IVY-1423,
  IVY-1424 and recently a patch concerning the useorigin attribute for
  the case of URL resources which happen to be files.

 +1

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Release of IvyDE 2.2.0.final

2013-11-19 Thread Jean-Louis Boudart
Sorry of the delay.

Here is my +1 tested on a few projects without particular issues.


2013/11/19 Antoine Levy Lambert anto...@gmx.de

 +1 from me too,

 good work Nicolas,

 Antoine
 On Nov 10, 2013, at 3:25 PM, Nicolas Lalevée wrote:

 
  Le 10 nov. 2013 à 10:15, Stefan Bodewig bode...@apache.org a écrit :
 
  On 2013-11-09, Nicolas Lalevée wrote:
 
  The tag is here:
 http://svn.apache.org/repos/asf/ant/ivy/ivyde/tags/2.2.0.final/
 
  You can download the distribution from this URL:
 https://dist.apache.org/repos/dist/dev/ant/ivyde/2.2.0.final/
 
  as usual, I won't pretend I could judge the release based on content.
 
  hashes and signatures are good, source tarball matches the tag.
 
  +1 for the release as is.
 
  One small nit, two files contain $Date$ sequences which svn likes to
  expand based on the current locale, you may want to remove those
  variables from
 
 doc/screenshot-projects/commons-httpclient-3.0/src/java/org/apache/commons/httpclient/HttpStatus.java
  and TestHttpStatus.java.
 
  Cleaned up.
 
 
 org.apache.ivyde.eclipse.resolvevisualizer/src/org/apache/ivyde/eclipse/resolvevisualizer/Plugin.java
  is missing the license header, this really should be fixed.
 
  Indeed.
  I have updated the release doc to do a last check of the RAT report,
 which I should have done.
 
  Thanks !
 
  Nicolas
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Java version of Ivy/IvyDE

2013-09-03 Thread Jean-Louis Boudart
So what do you think ?
 [ ] we should continue to support Java 1.4
 [ ] we should make Ivy and IvyDE require Java 5
 [x] we should make Ivy and IvyDE require Java 6



-- 
Jean Louis Boudart
http://ant.apache.org/easyant/


Re: Easyant - Plugin conflict management

2013-08-28 Thread Jean-Louis Boudart
My answers below


2013/8/26 Dridi Boukelmoune dridi.boukelmo...@zenika.com

  Point 2 : Even if there is no much activity, i suggest to keep backward
  compatibility
 
  fine for me.

 Not necessary from my point of view. My only advice is to avoid legacy
 (or technical debt ;) at such early time.

 I was suggesting to keep backward compatibility mainly because easyant is
build by easyant :). Though we need older plugins to build the new
easyant and vice et versa.


  Point 3 : By two steps i meant running a global resolve (for all plugins
  and buildtypes including transitive ones). And then have a second class
  invoked to perform individual import of ant build file by picking them
 from
  the ResolveReport.
 
  ok I see. This make totally sense.

 This is where I'm lost. Actually the whole issue of dependencies
 conflicts between plugins.

 Here is the behavior I think I've observed with Maven:
 - maven resolves project dependencies and does a shitty job at
 conflicts resolution
 - maven resolves plugins dependencies one by one and downloads them lazily
 - each plugin is executed with its own classloader, and doesn't care
 about other plugins dependencies
 - I can get a dozen versions of the infamous[1] plexus-utils in a single
 build

 My point is, given proper isolation, is it a real issue to have
 different plugins depending on different versions of the same modules
 ?


The main point is to avoid having dozen version of jars :). But we also
have a internal limitation, ant doesn't load a buildfile two times. So if
we have many plugins relying on abstract ones, abstract ones must be
uniquely resolved.

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


Re: Easyant - Plugin conflict management

2013-08-20 Thread Jean-Louis Boudart
I've commited changes on trunk with some unit tests if you want to have a
look.

Known limitation :
 * system plugins doesn't participate *yet* to global plugin resolution
 * plugins classpath created dinamically will all contains the whole
resolution graph (not really a problem)

Point 1 : this can even affect performance. Invoking resolve process one
time seems much more speed that invoking plugins individually.
Point 2 : Even if there is no much activity, i suggest to keep backward
compatibility
Point 3 : By two steps i meant running a global resolve (for all plugins
and buildtypes including transitive ones). And then have a second class
invoked to perform individual import of ant build file by picking them from
the ResolveReport.
You can check  ResolvePlugins and ImportDeferred class in trunk if you want
to see concrete stuff.




2013/8/17 Nicolas Lalevée nicolas.lale...@hibnet.org

 Long overdue response.

 Le 3 août 2013 à 13:33, Jean-Louis Boudart jeanlouis.boud...@gmail.com
 a écrit :

  Hi there,
 
  It becomes necesssary to manage conflicts between plugins.
  This issues has been raised many time and is referenced on jira[1].
 
  Currently easyant offers import task taking some specific attributes to
  resolve a plugin (mainly organisation, module name and revision).
  ea:import org=mycompany module=myplugin revision=x.x/
 
  This task will :
  * resolve the given plugin or buildtypr
  * create a dynamic classpath for this plugin
  * expose location of others extra files through properties (ex
  checkstyle.xml containing checkstyle rules, this files is shipped in the
  plugin). Thoses properties will then be reused by the plugin itself
  * import the real ant file (invoke the importTask from ant core under the
  hood)
 
  This task is currently used :
  * dynamically by easyant to load system plugins (skeletons for example)
  * dynamically by easyant when you specify ea:build or ea:plugin tags
  in module.ivy files
  * invoked in plugin ant file itselfs
  * invoked in module.ant if users has complex needs
 
  Additionnal there is two alliases for this task to import plugins and
  buildtype.
  ea:plugin module=compile-java revision=0.9/
  ea:plugin module=build-std-java revision=0.9/
  If organisation attribute is not specified on aliases  default one will
 be
  used.
 
  It does the job but it doesn't handle conflict between plugins.
 
  Some plugins relies on abstract ones.
  Exemple:
  package-jar depends on abstract-package, abstract-package depends on
  abstract-compile, but compile-java plugin also depends on
 abstract-compile.
  Which versi of abstract-compile will be taken in case both plugins load
  different version ? The answer is the first one !
  This becomes more problematic on buildtypes, as buildtypes loads a set of
  plugins (including themself others abstract-plugins).
 
  Ok so now you should have a quick picture of the problem.
 
  What could be done  ?
 
  We can rely on ivy to describe dependency on plugins. But then how could
 we
  know in which order plugins should be loaded ?
 
  I suggest to introduce a deferred import mechanism.
 
  We should split responsibility in two distinct steps.
  1 - resolve (based on ivy) the whole graph of plugins and store the
 resolve
  report somewhere as a reusable reference in ant project
  2 - invoke a new import task should import already resolved plugins (the
  task could rely on the report stored as a reference in ant project)
 
  Exemple :
  compile java will have an ivy dependency on abstract-compile
  dependency org=org.apache.easyant.plugins module=abstract-compile
  revision=1.0/
 
  The compile java ant script will import the resolved plugin
  ea:import-deferred org=org.apache.easyant.plugins
  module=abstract-compile/
 
  Note that i'm not fixed yet with the task name. Any suggestion (even for
  alliases are welcome).
 
  To maintain backward compatibility i'm in favor of creating new aliases
  import-plugin and import-buildtype instead of reusing existing ones.
 
  People would be able to continue using existing task with known the
  limitation (no conflict management on plugins).
  This can help if someone wants to load plugins in module.ant after
 setting
  a few properties.
 
  I also recommend adding a warning on existing task to recommend people
  using the new import mechanism.
 
  What do you think ?

 I see 3 points here.

 First, managing plugin dependencies: with Ivy, of course, we couldn't
 agree more :)

 Then about creating new tasks to keep backward compatibility. I think we
 can break backward compatibility. Easyant is not yet 1.0 and I do not see
 much activity on the user list. I would prefer bugging the current users
 than having an error-prone and deprecated task around.

 Third there is the resolve in two steps. I really like the idea. I am not
 sure though if we need this in order to bring conflict management in plugin
 dependencies. And I am not sure how far you are willing to go.
 Actually

Easyant - Plugin conflict management

2013-08-03 Thread Jean-Louis Boudart
Hi there,

It becomes necesssary to manage conflicts between plugins.
This issues has been raised many time and is referenced on jira[1].

Currently easyant offers import task taking some specific attributes to
resolve a plugin (mainly organisation, module name and revision).
ea:import org=mycompany module=myplugin revision=x.x/

This task will :
 * resolve the given plugin or buildtypr
 * create a dynamic classpath for this plugin
 * expose location of others extra files through properties (ex
checkstyle.xml containing checkstyle rules, this files is shipped in the
plugin). Thoses properties will then be reused by the plugin itself
 * import the real ant file (invoke the importTask from ant core under the
hood)

This task is currently used :
 * dynamically by easyant to load system plugins (skeletons for example)
 * dynamically by easyant when you specify ea:build or ea:plugin tags
in module.ivy files
 * invoked in plugin ant file itselfs
 * invoked in module.ant if users has complex needs

Additionnal there is two alliases for this task to import plugins and
buildtype.
ea:plugin module=compile-java revision=0.9/
ea:plugin module=build-std-java revision=0.9/
If organisation attribute is not specified on aliases  default one will be
used.

It does the job but it doesn't handle conflict between plugins.

Some plugins relies on abstract ones.
Exemple:
package-jar depends on abstract-package, abstract-package depends on
abstract-compile, but compile-java plugin also depends on abstract-compile.
Which versi of abstract-compile will be taken in case both plugins load
different version ? The answer is the first one !
This becomes more problematic on buildtypes, as buildtypes loads a set of
plugins (including themself others abstract-plugins).

Ok so now you should have a quick picture of the problem.

What could be done  ?

We can rely on ivy to describe dependency on plugins. But then how could we
know in which order plugins should be loaded ?

I suggest to introduce a deferred import mechanism.

We should split responsibility in two distinct steps.
1 - resolve (based on ivy) the whole graph of plugins and store the resolve
report somewhere as a reusable reference in ant project
2 - invoke a new import task should import already resolved plugins (the
task could rely on the report stored as a reference in ant project)

Exemple :
compile java will have an ivy dependency on abstract-compile
dependency org=org.apache.easyant.plugins module=abstract-compile
revision=1.0/

The compile java ant script will import the resolved plugin
ea:import-deferred org=org.apache.easyant.plugins
module=abstract-compile/

Note that i'm not fixed yet with the task name. Any suggestion (even for
alliases are welcome).

To maintain backward compatibility i'm in favor of creating new aliases
import-plugin and import-buildtype instead of reusing existing ones.

People would be able to continue using existing task with known the
limitation (no conflict management on plugins).
This can help if someone wants to load plugins in module.ant after setting
a few properties.

I also recommend adding a warning on existing task to recommend people
using the new import mechanism.

What do you think ?ea

[1] https://issues.apache.org/jira/browse/EASYANT-13
-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/


Re: [VOTE] Release Ant 1.9.2

2013-07-09 Thread Jean-Louis Boudart
+1


2013/7/9 Stefan Bodewig bode...@apache.org

 Hi all,

 a very small release with some bugfixes in addition to the workaround
 for Oracle's javadoc vulnerability.

 I propose to adopt the following as Ant 1.9.2

 SVN tag: http://svn.apache.org/repos/asf/ant/core/tags/ANT_192/
 revision 1500831
 Tarballs: https://dist.apache.org/repos/dist/dev/ant/
 revision 2394
 Maven Artifacts:

 https://repository.apache.org/content/repositories/orgapacheant-116/org/apache/ant/

 Vote will be open for about 72 hours

 Cheers

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Cutting a Release because of the Javadoc Vulnerability?

2013-07-06 Thread Jean-Louis Boudart
+1


2013/7/6 Matt Benson gudnabr...@gmail.com

 Sounds like a good idea. Thanks Stefan!

 Matt
 On Jul 5, 2013 9:36 AM, Stefan Bodewig bode...@apache.org wrote:

  Hi all,
 
  as you most probably know Oracle's javadoc tool prior to Java 7u25
  creates javadocs with a frame injection vulnerability - see
  CVE-2013-1571, VU#225657 for details.
 
  The javadoc task in trunk contains a patch based on code by Uwe
  Schindler of the Lucene community that postprocesses javadoc's output,
  identifies vulnerable pages and fixes them.
 
  This is similar to the patch applied to Maven's javadoc plugin which led
  to their version 2.9.1.
 
  Do we want to cut an Ant release to help Ant users to get around the
  vulnerability or is the macrodef I've added to the online manual enough
  in our view?
 
  If enough people think we should cut a release then I guess I'm
  volunteering to be the RM.
 
  Stefan
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org
 
 




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


Re: Check available updates for libs in ivy

2013-06-04 Thread Jean-Louis Boudart
Hi,

As far as i know there is no quick way to do this yet.

As this feature is also neededi have spend a couple of hours on
it yesterday. I have a something working and i would be able to commit it
soon.

Basically it's a new ant task. The task try to resolve all libs with a
configurable revision (latest.release) by default and log :

   - dependency updates
   - new transitive dependencies
   - missing transitive dependencies (in case you upgrade a dependency and
   one of it's dependency disappear you rely on a new version)

The task  will be a post resolve task [1], so all commons attributes would
be available including inline=true :p.


As mentioned before you will be able to change the revision to check so if
you want to see potential updates including integration revision you
could do something like :
ivy:displaydependencyupdate revisiontocheck=latest.integration/


Would this cover your need ?

[1]
http://ant.apache.org/ivy/history/latest-milestone/use/postresolvetask.html

PS: the name of the task and attributes is not the final one :p if you have
a better idea you're welcome

2013/6/3 Mykhailo Oleksiuk mykhailo.oleks...@gmail.com

 Hi,

 Unfortunately I didn't get response from ivy-user group.

 Dev guys, could you help me with my question?

  Is it possible to get list of libs that are not up-to-date in quick
 way(ivy command/script/ant task etc)?


 Thanks,
 Mykhailo.


 -- Forwarded message --
 From: Mykhailo Oleksiuk mykhailo.oleks...@gmail.com
 Date: Tue, May 28, 2013 at 10:09 AM
 Subject: Check available updates for libs in ivy
 To: ivy-u...@ant.apache.org


 Hi,

 We have a big project with 100+ libs defined in ivy.xml.

 Is it possible to get list of libs that are not up-to-date in quick way(ivy
 command/script/ant task etc)?

 --
 Regards,
 Mykhailo Oleksiuk.



 --
 Regards,
 Mykhailo Oleksiuk.




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


Re: [VOTE] Ant 1.9.1 Release

2013-05-19 Thread Jean-Louis Boudart
+1


2013/5/16 Antoine Levy Lambert anto...@gmx.de

 Hi,

 I have uploaded candidate artefacts for an ant 1.9.1 release to :
 http://people.apache.org/~antoine/dist

 Let's vote on releasing these.


 Let's start with my own +1.

 Regards,

 Antoine

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Evaluating Bintray as a distribution platform for easyant plugins

2013-05-09 Thread Jean-Louis Boudart
Let's first define a few things.

We need to distribute many things :

   - easyant distribution itself (shipping ivy, ant and easyant-core.jar
   itself). As the entry point of easyant it remains natural to be
   distributed through dist.apache.org


   - additionnal task we may write in future. If we produce external ant
   task it make sense to distribute them through maven central to be reused
   outside of easyant context


   - plugins / buildtypes / skeletons are extension of easyant providing
   ready to use stuff.


Now let's focus on plugins/buildtypes and skeletons:
Existing *plugins* are plain xml build script (example of junit plugin [1])
. They only make sense in easyant context, and are not packaged as jars.
Some plugins may provide additionnal files (properties, xml, etc...). In a
near future we could imagine having plugins / buildtypes written with other
languages (ie. ant javafront, groovyfront, antdsl).

A *buildtype* is a superpset of plugins providing a lifecycle with a set of
ready to use plugins.

*Skeletons* are similar to maven archetypes (ie. templates of projects).

Plugins, buildtypes and skeletons have their own release lifecycle. We
could for example release intermediary release of junit plugin without
recreating a new easyant distribution.
As easyant is based on ivy we have many options to publish / resolve.

To leverage standard plugins (the basic one to make java projects) we could
ship them in easyant distribution (this was done through a JarResolver [2]
in our first release :)).
If you download 0.9 artifacts should be retrieved stuff from
easyant-core.jar itself except if you use more recent plugins (or ones not
included in the distribution).

We may have in future plugins that couldn't be hosted as ASF as they may
have incompatible licenses. It's for example the case for chekstyle/sonar
plugins.
It would be easier if have *one entry point* for users. That's why we
created http://repository.easyant.org.

Then we could isolate apache plugins from external ones by having two
internal repositories :

   - http://repository.easyant.org/apache-easyant/


   - http://repository.easyant.org/community-easyant/

The same can be done on bintray with a better reliability.

I don't think maven central is a good host for easyant plugins. Publishing
with a m2compatible layout sounds limiting to me as it quickly force us to
play with classifier when we have many artifacts.
Note that maven central / repository.apache.org only distribute .jar
files. On both you MUST provide a pom.xml which doesn't make sense for us.

How i imagine things ?


   1. EasyAnt plugins / buildtypes / skeletons should be released on public
   repositories individually.
   2. Public repository will become main references to distribute/fetch
   internal stuff for easyant (plugins,buildtypes, skeletons).
   3. Single *entry point* for users even if we may have two internal
   repositories to distinguish apache artifacts from community ones
   4. Public repository may provide a simple way to browse/search existing
   stuff.
   5. When a new easyant distribution is created we should ship a set of
   plugins in the distribution itself by copying them from public repository
   (the reference :))

I would add two extra requirements for public repository :

   1. Plugins / buildtypes documentation should be accessible closed to
   artifacts (can be done through readmore files on bintray [3])
   2. It should provide download statistics


[1]
https://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/junit/src/main/resources/junit.ant
[2] http://ant.apache.org/ivy/history/latest-milestone/resolver/jar.html
[3]
https://bintray.com/pkg/show/readmore/easyant/community-plugins/sonar-easyant-plugin




2013/5/6 Antoine Levy Lambert anto...@gmx.de

 No objections from me.

 Antoine
 On May 3, 2013, at 6:04 AM, Jean-Louis Boudart wrote:

  No objections either if both Apache  non Apache plugins are on bintray
 ? :p
 
 
  2013/5/3 Jan Matèrne (jhm) apa...@materne.de
 
  Neither from me.
  My objections were for ASF plugins not for outside ASF ;)
 
  Jan
 
  -Ursprüngliche Nachricht-
  Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
  Gesendet: Freitag, 3. Mai 2013 10:06
  An: Ant Developers List
  Betreff: Re: Evaluating Bintray as a distribution platform for easyant
  plugins
 
  Hello Jean-Louis,
 
  I was not aware of bintray, I have just looked at the web site.
 
  No objections from me.
 
  Regards,
 
 
  Antoine
  On May 3, 2013, at 2:14 AM, Jean-Louis Boudart wrote:
 
  No objections? :p
  Le 29 avr. 2013 20:59, Jean-Louis Boudart
  jeanlouis.boud...@gmail.com a écrit :
 
  Here is the original thread from easyant-dev ML during apache
  incubation :
  http://markmail.org/thread/uv2xkj63rkdh2thh
  Le 29 avr. 2013 20:53, Jean-Louis Boudart
  jeanlouis.boud...@gmail.com a écrit :
 
 
  I would prefer having the artifacts on ASF servers. A (Nexus
  based)
  repository is at https://repository.apache.org/ Ant + Ivy

Re: Adding if/unless conditions on commandline args

2013-05-09 Thread Jean-Louis Boudart
I'm not a big fan of adding this feature through internal namespaces, was
there any complication to do it without namespaces ?

Anyway it does the job, and stuff looks extensible so i'm fine with current
solution if no one objects.

49036 add 'unless' attribute to JUnit test element was already solved
isn't it ?



2013/5/6 Peter Reilly peter.kitt.rei...@gmail.com

 wow, I had forgot about that!

 Peter


 On Mon, May 6, 2013 at 12:55 AM, Antoine Levy Lambert anto...@gmx.de
 wrote:

  Hi,
 
  I have committed a patch created by Peter Reilly back in 2007.
 
  The bugzilla PR is 43362 [1]
 
  If the community is happy with this change we will be able to close a
  number of bug reports requesting if/unless on various elements .
  For instance 49136 requesting if/unless support for attribute nested
  element of manifest task,
  49036 add 'unless' attribute to JUnit test element,
  ...
 
  Regards,
 
  Antoine
 
  [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=43362
 
  On May 3, 2013, at 5:37 AM, Jan Matèrne (jhm) wrote:
 
   AFAIK this was discussed several times in the past (few years) with the
   result, that having if/unless an _all_ elements would decrease
   maintainability of the build scripts.
  
   But +1 from me for having if/unless on nested elements.
  
   What about supporting more complex conditions via nested condition
   elements?
  
  
   Jan
  
   -Ursprüngliche Nachricht-
   Von: Michael Clarke [mailto:michael.m.cla...@gmail.com]
   Gesendet: Freitag, 3. Mai 2013 11:01
   An: Ant Developers List
   Betreff: Re: Adding if/unless conditions on commandline args
  
   +1 from me too
  
   On 3 May 2013, at 09:37, Jean-Louis Boudart
   jeanlouis.boud...@gmail.com wrote:
  
   +1
  
  
   2013/5/3 Antoine Levy Lambert anto...@gmx.de
  
   I wonder whether we could not add if an unless on all nested
   elements
   in the framework ?
  
  
   Regards,
  
   Antoine
   On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote:
  
   Hi,
  
   It's currently difficult to make reusable script when using exec
   task
   or
   any other task using commandline args.
   We oftenly need some dynamic arguments and this can be
   complicated.
  
   Therefor, i suggest to introduce if/unless conditions on comand
   line
   args :
  
   exec executable=git
   arg value=commit/
   arg line=-a if=${commit.all.files}/  arg value=-m/  arg
   value=${commit.message}/ /exec
  
   I have a working implementation  with related tests and
   documentation.
   Commandline.Arg class now extends ProjectComponent, and expose
   accessors for if/unless condition, and rely on PropertyHelper to
   check conditions.
  
   Is this sufficient ? From what i have seen, it doesn't break
   backward compatibility at least all tests are green :p.
  
   The setProject(Project p) method should be invoked automatically
   by ProjectHelper isn't it ?
  
   If ant is used in pure java and we ommited invoking
   setProject(Project p) method, it should also works as
   PropertyHelper seems null safe.
  
   If there is no objection i will commit this this week end.
  
  
   
   -
   To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For
   additional
   commands, e-mail: dev-h...@ant.apache.org
  
  
  
  
   --
   Jean Louis Boudart
   Independent consultant
   Apache EasyAnt commiter http://ant.apache.org/easyant/
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
   commands, e-mail: dev-h...@ant.apache.org
  
  
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
   For additional commands, e-mail: dev-h...@ant.apache.org
  
 
 




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


Re: AW: Evaluating Bintray as a distribution platform for easyant plugins

2013-05-03 Thread Jean-Louis Boudart
No objections? :p
Le 29 avr. 2013 20:59, Jean-Louis Boudart jeanlouis.boud...@gmail.com a
écrit :

 Here is the original thread from easyant-dev ML during apache incubation :
 http://markmail.org/thread/uv2xkj63rkdh2thh
  Le 29 avr. 2013 20:53, Jean-Louis Boudart jeanlouis.boud...@gmail.com
 a écrit :


  I would prefer having the artifacts on ASF servers. A (Nexus based)
  repository is at https://repository.apache.org/
  Ant + Ivy are available at
  https://repository.apache.org/content/repositories/releases/

 I would also prefer this but will ASF authorize non apache project
 (read plugins with incompatible licences for example) to publish there ? I
 don't think so.
 By the way you really got the idea, have one connection point to ease
 understanding for the community. That's why we intially setup a online
 repository (repo.easyant.org) with two internal repository :
 * one for apache plugins
 * one for non apache plugins (the one having potential issues with
 licenses like sonar or checkstyle)

 I was suggesting to reproduce this on bintray.

 If this could be done @ASF i would definitively go in that direction !
 But is this really possible ?

   As bintray and github supports Markdown syntax, i made some
   experimentation on plugin documentation generation.
 
  Are you writing the markdown by hand or do you generate that from java
  source?
 Generated through easyant plugin report task (
 http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl)
  with a custom xsl (
 http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl
 )

 
 
   Result on github : https://github.com/easyant/sonar-easyant-plugin
   Result on bintray :
  
 https://bintray.com/pkg/show/readmore/easyant/community-plugins/sonar-
   easyant-plugin
 
  On BinTray the tables are broken.
  No syntax highlighting on BT?
 I also reported this.

  Git support is growing at ASF, e.g. Camel is on the migration path from
 svn
  to git.
  A blocker to their vote is
  https://issues.apache.org/jira/browse/INFRA-6197
 Nice to know :). I was talking here for non apache plugins/




Adding if/unless conditions on commandline args

2013-05-03 Thread Jean-Louis Boudart
Hi,

It's currently difficult to make reusable script when using exec task or
any other task using commandline args.
We oftenly need some dynamic arguments and this can be complicated.

Therefor, i suggest to introduce if/unless conditions on comand line args :

exec executable=git
   arg value=commit/
   arg line=-a if=${commit.all.files}/
   arg value=-m/
   arg value=${commit.message}/
/exec

I have a working implementation  with related tests and documentation.
Commandline.Arg class now extends ProjectComponent, and expose accessors
for if/unless condition, and rely on PropertyHelper to check conditions.

Is this sufficient ? From what i have seen, it doesn't break backward
compatibility at least all tests are green :p.

The setProject(Project p) method should be invoked automatically by
ProjectHelper isn't it ?

If ant is used in pure java and we ommited invoking setProject(Project p)
method, it should also works as PropertyHelper seems null safe.

If there is no objection i will commit this this week end.


Re: Adding if/unless conditions on commandline args

2013-05-03 Thread Jean-Louis Boudart
+1


2013/5/3 Antoine Levy Lambert anto...@gmx.de

 I wonder whether we could not add if an unless on all nested elements in
 the framework ?


 Regards,

 Antoine
 On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote:

  Hi,
 
  It's currently difficult to make reusable script when using exec task
 or
  any other task using commandline args.
  We oftenly need some dynamic arguments and this can be complicated.
 
  Therefor, i suggest to introduce if/unless conditions on comand line
 args :
 
  exec executable=git
arg value=commit/
arg line=-a if=${commit.all.files}/
arg value=-m/
arg value=${commit.message}/
  /exec
 
  I have a working implementation  with related tests and documentation.
  Commandline.Arg class now extends ProjectComponent, and expose accessors
  for if/unless condition, and rely on PropertyHelper to check conditions.
 
  Is this sufficient ? From what i have seen, it doesn't break backward
  compatibility at least all tests are green :p.
 
  The setProject(Project p) method should be invoked automatically by
  ProjectHelper isn't it ?
 
  If ant is used in pure java and we ommited invoking setProject(Project p)
  method, it should also works as PropertyHelper seems null safe.
 
  If there is no objection i will commit this this week end.


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: Adding if/unless conditions on commandline args

2013-05-03 Thread Jean-Louis Boudart
By the way i don't know yet where we can plugin tests on if/unless
condition in this case.


2013/5/3 Jean-Louis Boudart jeanlouis.boud...@gmail.com

 +1


 2013/5/3 Antoine Levy Lambert anto...@gmx.de

 I wonder whether we could not add if an unless on all nested elements in
 the framework ?


 Regards,

 Antoine
 On May 3, 2013, at 2:57 AM, Jean-Louis Boudart wrote:

  Hi,
 
  It's currently difficult to make reusable script when using exec task
 or
  any other task using commandline args.
  We oftenly need some dynamic arguments and this can be complicated.
 
  Therefor, i suggest to introduce if/unless conditions on comand line
 args :
 
  exec executable=git
arg value=commit/
arg line=-a if=${commit.all.files}/
arg value=-m/
arg value=${commit.message}/
  /exec
 
  I have a working implementation  with related tests and documentation.
  Commandline.Arg class now extends ProjectComponent, and expose accessors
  for if/unless condition, and rely on PropertyHelper to check conditions.
 
  Is this sufficient ? From what i have seen, it doesn't break backward
  compatibility at least all tests are green :p.
 
  The setProject(Project p) method should be invoked automatically by
  ProjectHelper isn't it ?
 
  If ant is used in pure java and we ommited invoking setProject(Project
 p)
  method, it should also works as PropertyHelper seems null safe.
 
  If there is no objection i will commit this this week end.


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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




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


Re: Evaluating Bintray as a distribution platform for easyant plugins

2013-05-03 Thread Jean-Louis Boudart
No objections either if both Apache  non Apache plugins are on bintray ? :p


2013/5/3 Jan Matèrne (jhm) apa...@materne.de

 Neither from me.
 My objections were for ASF plugins not for outside ASF ;)

 Jan

  -Ursprüngliche Nachricht-
  Von: Antoine Levy Lambert [mailto:anto...@gmx.de]
  Gesendet: Freitag, 3. Mai 2013 10:06
  An: Ant Developers List
  Betreff: Re: Evaluating Bintray as a distribution platform for easyant
  plugins
 
  Hello Jean-Louis,
 
  I was not aware of bintray, I have just looked at the web site.
 
  No objections from me.
 
  Regards,
 
 
  Antoine
  On May 3, 2013, at 2:14 AM, Jean-Louis Boudart wrote:
 
   No objections? :p
   Le 29 avr. 2013 20:59, Jean-Louis Boudart
   jeanlouis.boud...@gmail.com a écrit :
  
   Here is the original thread from easyant-dev ML during apache
  incubation :
   http://markmail.org/thread/uv2xkj63rkdh2thh
   Le 29 avr. 2013 20:53, Jean-Louis Boudart
   jeanlouis.boud...@gmail.com a écrit :
  
  
   I would prefer having the artifacts on ASF servers. A (Nexus
  based)
   repository is at https://repository.apache.org/ Ant + Ivy are
   available at
   https://repository.apache.org/content/repositories/releases/
  
   I would also prefer this but will ASF authorize non apache
  project
   (read plugins with incompatible licences for example) to publish
   there ? I don't think so.
   By the way you really got the idea, have one connection point to
   ease understanding for the community. That's why we intially setup
  a
   online repository (repo.easyant.org) with two internal repository :
   * one for apache plugins
   * one for non apache plugins (the one having potential issues
  with
   licenses like sonar or checkstyle)
  
   I was suggesting to reproduce this on bintray.
  
   If this could be done @ASF i would definitively go in that
  direction !
   But is this really possible ?
  
   As bintray and github supports Markdown syntax, i made some
   experimentation on plugin documentation generation.
  
   Are you writing the markdown by hand or do you generate that from
   java source?
   Generated through easyant plugin report task (
   http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-
  pl
   ugin-documentation/src/main/resources/easyant-report-mardown.xsl)
   with a custom xsl (
   http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-
  pl
   ugin-documentation/src/main/resources/easyant-report-mardown.xsl
   )
  
  
  
   Result on github : https://github.com/easyant/sonar-easyant-
  plugin
   Result on bintray :
  
   https://bintray.com/pkg/show/readmore/easyant/community-
  plugins/sona
   r-
   easyant-plugin
  
   On BinTray the tables are broken.
   No syntax highlighting on BT?
   I also reported this.
  
   Git support is growing at ASF, e.g. Camel is on the migration path
   from
   svn
   to git.
   A blocker to their vote is
   https://issues.apache.org/jira/browse/INFRA-6197
   Nice to know :). I was talking here for non apache plugins/
  
  
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional
  commands, e-mail: dev-h...@ant.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: AW: Evaluating Bintray as a distribution platform for easyant plugins

2013-04-29 Thread Jean-Louis Boudart
 I would prefer having the artifacts on ASF servers. A (Nexus based)
 repository is at https://repository.apache.org/
 Ant + Ivy are available at
 https://repository.apache.org/content/repositories/releases/

I would also prefer this but will ASF authorize non apache project (read
plugins with incompatible licences for example) to publish there ? I don't
think so.
By the way you really got the idea, have one connection point to ease
understanding for the community. That's why we intially setup a online
repository (repo.easyant.org) with two internal repository :
* one for apache plugins
* one for non apache plugins (the one having potential issues with
licenses like sonar or checkstyle)

I was suggesting to reproduce this on bintray.

If this could be done @ASF i would definitively go in that direction ! But
is this really possible ?

  As bintray and github supports Markdown syntax, i made some
  experimentation on plugin documentation generation.

 Are you writing the markdown by hand or do you generate that from java
 source?
Generated through easyant plugin report task (
http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl)
with a custom xsl (
http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl
)



  Result on github : https://github.com/easyant/sonar-easyant-plugin
  Result on bintray :
  https://bintray.com/pkg/show/readmore/easyant/community-plugins/sonar-
  easyant-plugin

 On BinTray the tables are broken.
 No syntax highlighting on BT?
I also reported this.

 Git support is growing at ASF, e.g. Camel is on the migration path from
svn
 to git.
 A blocker to their vote is
 https://issues.apache.org/jira/browse/INFRA-6197
Nice to know :). I was talking here for non apache plugins/


Re: AW: Evaluating Bintray as a distribution platform for easyant plugins

2013-04-29 Thread Jean-Louis Boudart
Here is the original thread from easyant-dev ML during apache incubation :
http://markmail.org/thread/uv2xkj63rkdh2thh
 Le 29 avr. 2013 20:53, Jean-Louis Boudart jeanlouis.boud...@gmail.com
a écrit :


  I would prefer having the artifacts on ASF servers. A (Nexus based)
  repository is at https://repository.apache.org/
  Ant + Ivy are available at
  https://repository.apache.org/content/repositories/releases/

 I would also prefer this but will ASF authorize non apache project (read
 plugins with incompatible licences for example) to publish there ? I don't
 think so.
 By the way you really got the idea, have one connection point to ease
 understanding for the community. That's why we intially setup a online
 repository (repo.easyant.org) with two internal repository :
 * one for apache plugins
 * one for non apache plugins (the one having potential issues with
 licenses like sonar or checkstyle)

 I was suggesting to reproduce this on bintray.

 If this could be done @ASF i would definitively go in that direction ! But
 is this really possible ?

   As bintray and github supports Markdown syntax, i made some
   experimentation on plugin documentation generation.
 
  Are you writing the markdown by hand or do you generate that from java
  source?
 Generated through easyant plugin report task (
 http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl)
  with a custom xsl (
 http://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/easyant-plugin-documentation/src/main/resources/easyant-report-mardown.xsl
 )

 
 
   Result on github : https://github.com/easyant/sonar-easyant-plugin
   Result on bintray :
   https://bintray.com/pkg/show/readmore/easyant/community-plugins/sonar-
   easyant-plugin
 
  On BinTray the tables are broken.
  No syntax highlighting on BT?
 I also reported this.

  Git support is growing at ASF, e.g. Camel is on the migration path from
 svn
  to git.
  A blocker to their vote is
  https://issues.apache.org/jira/browse/INFRA-6197
 Nice to know :). I was talking here for non apache plugins/



Evaluating Bintray as a distribution platform for easyant plugins

2013-04-28 Thread Jean-Louis Boudart
Dear EasyAnters,

I've been working on sonar integration as a plugin for easyant.
Source are hosted on github :https://github.com/easyant/sonar-easyant-plugin
.

Since a few weeks, JFrog (guys behind Artifactory) opened a new online
service for OpenSourcers : Bintray.
Bintray is a social service for developers to publish, download, store,
promote, and share open source software packages. With Bintray's full
self-service platform developers have full control over their published
software and how it is distributed to the world.

What would be the benefits for easyant ?
We currently have our own repostory (repository.easyant.org) hosted on a
private server. I would prefer to switch to a more reliable repository like
bintray. No need to worry about backup, disaster recovery. We could just
focus on content.

They also offers download statistics which could be interresting for us.

I created a repository to host community plugins :
https://bintray.com/repo/browse/easyant/community-plugins

To use it add the following resolver in your ivysettings.xml

url name=community-plugins
artifact pattern=
http://dl.bintray.com/content/easyant/community-plugins/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]/

ivy pattern=
http://dl.bintray.com/content/easyant/community-plugins/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]/

/url

Currently only sonar-easyant-plugin package is  available.

As bintray and github supports Markdown syntax, i made some
experimentation on plugin documentation generation.

Result on github : https://github.com/easyant/sonar-easyant-plugin
Result on bintray :
https://bintray.com/pkg/show/readmore/easyant/community-plugins/sonar-easyant-plugin

If sources are on github, read more page from github can be synced with
README.md. If not we can edit directly in bintray.

You can notice that Table markdown syntax seems broken on bintray (or not
supported yet). I reported it few minutes ago.

I'm really satisfied by the result and wondering if we should move our
plugins there. We can be backward compatible on exposed urll without effort.

What do you think?
-- 
Jean Louis Boudart
Independent consultant
Apache EasyAnt commiter http://ant.apache.org/easyant/


Re: Ant Homepage

2013-04-23 Thread Jean-Louis Boudart
2013/4/21 Jan Matèrne (jhm) apa...@materne.de

   I had a look at the homepage:
   * EasyAnt is not listed in the subproject section

 done

   * There is a graphic for ApacheCon, which is over.
  I think this is included dynamically from a site maintained by the
  ApacheCon committee - nothing much you'll be able to do.

 ok, keep unattended


   Also I have seen that the EasyAnt homepage itself spells it Easyant
   or EasyAnt (sometimes with upper A and sometimes with lower a).
  
   I think it should be with upper A ;-)
  
  I also prefer with a upper A !

 done

Thx :)


   Not sure if I should work here ...
  Contributions are welcome :)

 I could run a build using easyant publish-shared, but
 - I have to install a Java6 (Xooki) and Java5 (Ant regression) on my
 machine
 
 - I dont have an idea of how to generate the stuff in
 site\easyant\production

Calling easyant publish-shared will generate final documentation in
site\easyant\production, but as you pointed out it requires Java6. I'll
process it tonight.




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

 @Jean Louis: new URL for EasyAnt ;-)

Good catch ;)



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


Re: Ant Homepage

2013-04-21 Thread Jean-Louis Boudart
2013/4/20 Jan Matèrne j...@materne.de

 I had a look at the homepage:

 * EasyAnt is not listed in the subproject section

 * There is a graphic for ApacheCon, which is over.

 I prepared a commit for that.

 Should I commit?



 Also I have seen that the EasyAnt homepage itself spells it Easyant or
 EasyAnt (sometimes with upper A and sometimes with lower a).

 I think it should be with upper A ;-)

I also prefer with a upper A !



 Not sure if I should work here ...

Contributions are welcome :)






 After a long time of commits I want to be careful.

 What is the current process of updating the homepage?

 - modify the svn site module

 - run the build

 - commit

 - some more work here?



 Jan




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


Re: Some feedback on EasyAnt

2013-04-19 Thread Jean-Louis Boudart
Done on trunk
Le 17 avr. 2013 18:32, Xavier Hanin xavier.ha...@gmail.com a écrit :

 On Tue, Apr 16, 2013 at 8:19 AM, Jean-Louis Boudart 
 jeanlouis.boud...@gmail.com wrote:

  What is the desired behavior when junit is missing in project classpath ?
  1 - ignore test ? maybe with a message @info level ?
  2 - configure the plugin to use junit version specified in the project.
 and
  if no one is specified use the one specified by us in the plugin itself ?
 

 I think failing is ok, after all there is a dependency missing.

 My 2 c.

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



Re: Some feedback on EasyAnt

2013-04-16 Thread Jean-Louis Boudart
What is the desired behavior when junit is missing in project classpath ?
1 - ignore test ? maybe with a message @info level ?
2 - configure the plugin to use junit version specified in the project. and
if no one is specified use the one specified by us in the plugin itself ?


2013/4/15 Jean-Louis Boudart jeanlouis.boud...@gmail.com

 Hi Xavier,

 Thanks for your feedback !


 2013/4/15 Xavier Hanin xavier.ha...@gmail.com


 I've been playing a little bit with easyant 0.9 this wek-end, and I have
 some feedback:
 - I have some issues with the multi module example:
   - if I run easyant verify at the root I get an error: The classpath
 for junit must include junit.jar if not in Ant's own classpath
   - if I run easyant publish-local I get another error: bad revision
 found in ivy file (Revision: 0.2-local-20130415094618). Use forcedeliver
 or
 update

 Good catch i'll fix this now



 - from a documentation point of view, I have not found the documentation
 of
 plugins. Having links from the plugins and standard build types pages
 would
 be really nice. To change the compiler source and target version I had to
 check the source files.




 - the source files of plugins are pretty easy to read and understand, I
 think providing links to them or documentation on where to find them would
 be useful for people used to plain ant (maybe I just missed this part of
 the doc, I didn't read everything).

 Plugin documentation is not online yet. We didn't took time to find how to
 publish them as we may have differences in future plugin releases.
 We already have a way to generate plugin documentation. Adding links to
 plugin sources could be a good too.


 - I've written a small tool to convert basic (very basic I mean) pom files
 to module.ivy, and the result is interesting: on a bunch of modules, not
 only the build run perfectly well (it's really nice to use the same
 conventions), but also it's slightly faster: on a 22 multi module build, a
 easyant package take 19s against 23s for mvn -DskipTests=true install

 Nice to hear that it's easy to move from a standard maven build with
 multimodules to easyant. Will you share your tool to convert pom files to
 module.ivy ?



 To conclude there's room for improvement, but you've done a very good work
 especially on the maven compatibility side, which is great for people
 having a maven build.

 I plan to continue improving support for maven users. In early days of
 easyant we wrote a plugin to emulate maven publication (generating a pom
 and related metadatas) [1] . I saw ivy improvements on makepom task [2] and
 i believe we have work to do on both project to make life easier for maven
 users to reuse publicated artifacts by ivy/easyant.




 For the bugs and documentation improvements, I know I could contrbute
 myself, but I have to admit I don't have enough time to dedicate.

 No problem :)


 [1]
 https://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/maven-publication/
 [2] http://ant.apache.org/ivy/history/trunk/use/makepom.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/


Re: Some feedback on EasyAnt

2013-04-15 Thread Jean-Louis Boudart
Hi Xavier,

Thanks for your feedback !


2013/4/15 Xavier Hanin xavier.ha...@gmail.com


 I've been playing a little bit with easyant 0.9 this wek-end, and I have
 some feedback:
 - I have some issues with the multi module example:
   - if I run easyant verify at the root I get an error: The classpath
 for junit must include junit.jar if not in Ant's own classpath
   - if I run easyant publish-local I get another error: bad revision
 found in ivy file (Revision: 0.2-local-20130415094618). Use forcedeliver or
 update

Good catch i'll fix this now



 - from a documentation point of view, I have not found the documentation of
 plugins. Having links from the plugins and standard build types pages would
 be really nice. To change the compiler source and target version I had to
 check the source files.




 - the source files of plugins are pretty easy to read and understand, I
 think providing links to them or documentation on where to find them would
 be useful for people used to plain ant (maybe I just missed this part of
 the doc, I didn't read everything).

Plugin documentation is not online yet. We didn't took time to find how to
publish them as we may have differences in future plugin releases.
We already have a way to generate plugin documentation. Adding links to
plugin sources could be a good too.


 - I've written a small tool to convert basic (very basic I mean) pom files
 to module.ivy, and the result is interesting: on a bunch of modules, not
 only the build run perfectly well (it's really nice to use the same
 conventions), but also it's slightly faster: on a 22 multi module build, a
 easyant package take 19s against 23s for mvn -DskipTests=true install

Nice to hear that it's easy to move from a standard maven build with
multimodules to easyant. Will you share your tool to convert pom files to
module.ivy ?



 To conclude there's room for improvement, but you've done a very good work
 especially on the maven compatibility side, which is great for people
 having a maven build.

I plan to continue improving support for maven users. In early days of
easyant we wrote a plugin to emulate maven publication (generating a pom
and related metadatas) [1] . I saw ivy improvements on makepom task [2] and
i believe we have work to do on both project to make life easier for maven
users to reuse publicated artifacts by ivy/easyant.




 For the bugs and documentation improvements, I know I could contrbute
 myself, but I have to admit I don't have enough time to dedicate.

No problem :)


[1]
https://svn.apache.org/repos/asf/ant/easyant/plugins/trunk/maven-publication/
[2] http://ant.apache.org/ivy/history/trunk/use/makepom.html

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


Re: easyant4e binary

2013-04-07 Thread Jean-Louis Boudart
Hi,

Unfortunatly, easyant4e isn't released yet !
We still have work on it to sync with recent changes of easyant.


2013/4/2 Tim Enderling t.enderl...@intershop.de

 Hi,

 is easyant4e available as a prebuilt package/is there an Eclipse update
 site for it?

 Best regards
 Tim Enderling

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: EasyAnt is graduating

2013-03-27 Thread Jean-Louis Boudart
All infra request are now closed. Migration seems over! Long live
http://ant.apache.org/easyant/

PS: i think we forgot setuping redirection from incubator.a.o/easyant to
ant.a.o/easyant. I will fix this today
Le 23 mars 2013 15:25, Nicolas Lalevée nicolas.lale...@hibnet.org a
écrit :


 Le 16 mars 2013 à 01:39, Nicolas Lalevée nicolas.lale...@hibnet.org a
 écrit :

  Finally ! We're there !
 
  Now we need to move stuff. EasyAnt is graduating like Ivy did, so about
 the resources, here is the following suggestions.
 
  * The svn tree
  We will move the svn tree of EasyAnt under Ant's one. Everything except
 'KEYS' and 'site' under 
 http://svn.apache.org/repos/asf/incubator/easyant/will move into
 http://svn.apache.org/repos/asf/ant/easyant.

 done.

  We'll give write rights to EasyAnt committers on the entire Ant svn tree.

 We need to give r/w rights to Jérôme Benois (jbenois) and Siddhartha
 Purkayastha (kpsiddharth).

  * The website
  EasyAnt website is using the same publication mechanism as Ant. We'll
 need to move the svn tree of the site from
 http://svn.apache.org/repos/asf/incubator/easyant/site/ to
 http://svn.apache.org/repos/asf/ant/site/easyant.

 done.

  The web site will be at http://ant.apache.org/easyant
  We'll need to create an INFRA ticket about the move:
  - redirect from incubator/esayant to ant.apache.org/easyant (via
 http://svn.apache.org/repos/asf/incubator/public/trunk/content/.htaccess)

 I'll do as soon as the following infra ticket is closed.

  - change the svnpubsub

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

  * The mailing lists:
  - easyant-dev@ will be closed in favor of dev@ant.apache.org
  - easyant-commits@ will be closed in favor of
 notificati...@ant.apache.org
  - easyant-private@ just closed.

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

  * Jira:
  No need to do anything I think:
 https://issues.apache.org/jira/browse/EASYANT
  Just need to notify the infra that the notification list is now
 notificati...@ant.apache.org

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

  Maybe some changes in the Gump metadata and Jenkins jobs?
 
  Good catch. There is nothing in Gump about EasyAnt but there is in
 Jenkins. I'll update it too.

 done.

 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




Re: [VOTE] Michael Clarke as a committer

2013-03-12 Thread Jean-Louis Boudart
+1
Le 12 mars 2013 20:39, Maarten Coene maarten_co...@yahoo.com a écrit :

 +1

 Maarten




 
  From: Bruce Atherton br...@callenish.com
 To: dev@ant.apache.org
 Sent: Tuesday, March 12, 2013 6:03 PM
 Subject: [VOTE] Michael Clarke as  a committer

 I'd like to nominate Michael Clarke as a committer. Not only has he
 revamped our testing infrastructure to make it compatible with JUnit4, he
 has also worked on resolving older bugs in our bugzilla that touched on
 testing. Let's vote on it.

 [ ] +1 to add Michael Clarke as a committer
 [ ] -1 to disagree
 [ ] ±0 means I don't care.


 Here is my +1.

 Bruce


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org


Re: [VOTE] Ant 1.9.0 release [2nd attempt]

2013-03-10 Thread Jean-Louis Boudart
+1 on the release as is too
Works perfectly in easyant :)


2013/3/9 Stefan Bodewig bode...@apache.org

 +1 on the release as is.

 On 2013-03-08, Antoine Levy Lambert wrote:

  You can veto the release if it matters that much to you and I would
  then have to drop and recreate the 1.9.0 label and do a new build.

 Maybe I'm picking nits: you can't veto a release, this is a majority
 vote.

 Stefan

 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Fwd: [ANNOUNCE] Apache EasyAnt 0.9-incubating released

2013-03-04 Thread Jean-Louis Boudart
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


Re: [VOTE] Accept EasyAnt as a subproject - take 2

2013-02-28 Thread Jean-Louis Boudart
We will publish a updated documentation soon (probably tonight).

Currently, the community is really small as prior releases was using
patched version of Ant and Ivy (mainly to introduce missing features sur as
extensionPoints in Ant, or module inheritence in Ivy). This was probably a
major issue, and explain why we didn't communicate too much outside of
ant-dev mailing list about it.

We've made lot of work to contribute back our modifications to both tools
and we now use official releases. In future we plan to bring more valuable
features to both Ant and Ivy. This is one of the main reason motivating us
to enter in ASF.
In the meantime we changed a lot of structuring stuff in easyant itself to
remain flexible and easier to use.

This release is a huge step for the project. And it's now time to promote
EasyAnt as a usable tool and to widen the community.

Your feedback will be really appreciated.


2013/2/28 Tim Enderling t.enderl...@intershop.de

 Hi,

 I didn't know that EasyAnt is still alive. EasyAnt might be exactly what
 we are looking for in a solution to modularize our build system and
 software. Some questions:

 Is there a more up-to-date documentation than the one at
 http://incubator.apache.org/easyant/history/trunk/reference.html?Fromskimming 
 through (and besides there a quite a few obvious mistakes in it)
 it seems to refer to a release prior to 0.9.

 Also: How large is the community of EasyAnt, are there any references for
 software projects using it? (I tried to get an idea for that by searching
 for EasyAnt on stackoverflow, but that didn't turn out well.)

 Thanks a lot
 Tim Enderling

  -Original Message-
  From: Nicolas Lalevée [mailto:nicolas.lale...@hibnet.org]
  Sent: Mittwoch, 27. Februar 2013 19:44
  To: Ant Developers List
  Subject: [VOTE] Accept EasyAnt as a subproject - take 2
 
  Hi,
 
  This is the come back of the proposal of bringing EasyAnt under the
  umbrella of the Ant PMC.
 
  There were some discussion on incubator-general about the incubating
  hcatalog project being graduated under the umbrella of the Hive PMC. I
  think that our case is more clear and more standard regarding the ASF
  rules, but I'll remind here what is at stake, so there is no
  misunderstanding (I include myself on the potentially misunderstanding
  people).
 
  EasyAnt code will be brought into Ant's svn tree.
  EasyAnt committers will become Ant committers but not part of the PMC
 (on 5
  committers, 3 are already Ant ones, and 2 are part of Ant's PMC)
  The Ant PMC will be responsible for the code, the community, the next
  releases of EasyAnt.
 
  Just like for Ivy. And I like the way it worked. Further more considering
  my path, I think it is good that there is no special right management in
  svn. I started as an IvyDE committer, I ended improving myself Ivy and
 Ant.
 
  Since the last vote tentative, the activity on EasyAnt remained the same,
  somehow low but continuous, not much less than Ant developers activity.
 And
  lately we succeeded to get a release out.
 
  To get yourself an opinion, here are some links:
  - the EasyAnt project incubator page:
  http://incubator.apache.org/projects/easyant.html
  - the archive of the mailing lists
  http://mail-archives.apache.org/mod_mbox/incubator-easyant-commits/
  http://mail-archives.apache.org/mod_mbox/incubator-easyant-dev/
  - the release
  http://www.apache.org/dist/incubator/easyant
 
  So, should we accept EasyAnt as a subproject ?
  Please, cast your votes:
  [ ] +1, I accept
  [ ] +0, OK, but..
  [ ] -1, I disapprove, because..
 
  Nicolas
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
  For additional commands, e-mail: dev-h...@ant.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Accept EasyAnt as a subproject - take 2

2013-02-27 Thread Jean-Louis Boudart
[x] +1, I accept


2013/2/27 Nicolas Lalevée nicolas.lale...@hibnet.org

 Hi,

 This is the come back of the proposal of bringing EasyAnt under the
 umbrella of the Ant PMC.

 There were some discussion on incubator-general about the incubating
 hcatalog project being graduated under the umbrella of the Hive PMC. I
 think that our case is more clear and more standard regarding the ASF
 rules, but I'll remind here what is at stake, so there is no
 misunderstanding (I include myself on the potentially misunderstanding
 people).

 EasyAnt code will be brought into Ant's svn tree.
 EasyAnt committers will become Ant committers but not part of the PMC (on
 5 committers, 3 are already Ant ones, and 2 are part of Ant's PMC)
 The Ant PMC will be responsible for the code, the community, the next
 releases of EasyAnt.

 Just like for Ivy. And I like the way it worked. Further more considering
 my path, I think it is good that there is no special right management in
 svn. I started as an IvyDE committer, I ended improving myself Ivy and Ant.

 Since the last vote tentative, the activity on EasyAnt remained the same,
 somehow low but continuous, not much less than Ant developers activity. And
 lately we succeeded to get a release out.

 To get yourself an opinion, here are some links:
 - the EasyAnt project incubator page:
 http://incubator.apache.org/projects/easyant.html
 - the archive of the mailing lists
 http://mail-archives.apache.org/mod_mbox/incubator-easyant-commits/
 http://mail-archives.apache.org/mod_mbox/incubator-easyant-dev/
 - the release
 http://www.apache.org/dist/incubator/easyant

 So, should we accept EasyAnt as a subproject ?
 Please, cast your votes:
 [ ] +1, I accept
 [ ] +0, OK, but….
 [ ] -1, I disapprove, because….

 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




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


Re: [VOTE] Apache Ivy 2.3.0 release

2013-01-13 Thread Jean-Louis Boudart
+1
Tested within easyant and everything is fine :)


2013/1/13 Maarten Coene maarten_co...@yahoo.com

 Hi all,

 I've created the binaries containing the Apache Ivy 2.3.0 release.

 These binaries can be found here:
 https://dist.apache.org/repos/dist/dev/ant/ivy/2.3.0/

 Maven artifacts are here:
 https://repository.apache.org/content/repositories/orgapacheant-125/

 Eclipse Update site is located here:

 https://dist.apache.org/repos/dist/dev/ant/ivyde/updatesite/ivy-2.3.0.final_20130110142753/

 They are based on the following tag:
 https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.3.0/

 Do you vote for the release of these binaries?

   [ ] +1 Release these artifacts
   [ ] +0 OK, but...
   [ ] -0 OK, but really should fix...
   [ ] -1 I oppose this release because...

 kind regards,
 Maarten Coene




-- 
Jean Louis Boudart


Re: [RESULT][VOTE] Apache Ivy 2.3.0-RC2 release (2nd attempt)

2012-11-12 Thread Jean-Louis Boudart
I could also give some help but i dont know where to start.

Is the whole release process documented ? If yes could give me some
pointers?

Le 12 nov. 2012 23:09, Maarten Coene maarten_co...@yahoo.com a écrit :

 Thanks Nicolas,
 that would be really helpful! :-)


 Maarten



 
  From: Nicolas Lalevée nicolas.lale...@hibnet.org
 To: Ant Developers List dev@ant.apache.org
 Sent: Monday, November 12, 2012 11:02 PM
 Subject: Re: [RESULT][VOTE] Apache Ivy 2.3.0-RC2 release (2nd attempt)


 Le 12 nov. 2012 à 22:49, Maarten Coene maarten_co...@yahoo.com a écrit :

  Hi all,
 
  I'm pleased to announce that the vote for the Apache Ivy 2.3.0-RC2
 release has passed.
  There were +1 votes from Nicolas, Jean-Louis, Antoine and myself.
 
 
  I'll continue the release process the next couple of days.

 I can help with the Eclipse update site if you want.

 Nicolas


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org


Re: [VOTE] Apache Ivy 2.3.0-RC2 release (2nd attempt)

2012-11-06 Thread Jean-Louis Boudart
+1
Le 6 nov. 2012 14:07, Nicolas Lalevée nicolas.lale...@hibnet.org a
écrit :

 +1

 Nicolas

 Le 5 nov. 2012 à 23:37, Maarten Coene maarten_co...@yahoo.com a écrit :

  Hi all,
 
  Here is a new attempt to create the Apache Ivy 2.3.0-RC2 release.
  The only change compared to the first attempt is the version fix for the
 OSGI bundle.
  You can find the binaries here:
  https://dist.apache.org/repos/dist/dev/ant/ivy/2.3.0-rc2/
 
  A staging maven repository can be found here:
 
  https://repository.apache.org/content/repositories/orgapacheant-017/
 
  The SVN tag:
 
  https://svn.apache.org/repos/asf/ant/ivy/core/tags/2.3.0-rc2/
 
 
  Do you vote for the release of these binaries?
 
  [ ] Yes
  [ ] No
 
  regards,
  Maarten Coene


 -
 To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
 For additional commands, e-mail: dev-h...@ant.apache.org




  1   2   >