Re: archiving EasyAnt
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-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
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
+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
+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
+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
+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
+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
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
+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
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
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
+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
+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
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
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
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
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
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
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
+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
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
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
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
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 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
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
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
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
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 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
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
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
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
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
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
[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
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
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
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
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
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
+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
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
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
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
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
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
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)
+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
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 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
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
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 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
+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
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
+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
+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
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
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
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
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
+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
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
+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
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
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
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
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
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
+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?
+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
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
+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
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
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
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
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
+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
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
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
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
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
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/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/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
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
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
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
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
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
+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]
+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
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
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
[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
+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)
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)
+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