AW: archiving EasyAnt
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 --> done 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 --> done: This resource is not under Apache control. Jean-Louis has valid reasons to keep them alive. So retiring EasyAnt is complete. Jan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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) : > > 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 : > 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
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. > 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. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: archiving EasyAnt
> 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
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) : > 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.git Apache 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: archiving EasyAnt
On 2017-01-05, Jan Matèrne (jhm) wrote: > Retire: Releases > > --> open, doesnt have write privilege. > --> could someone else remove that directory? done Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: archiving EasyAnt
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
[ANN] Retirement of Ant subproject 'EasyAnt'
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]. Happy new year Jan Matèrne, on behalf of the Apache Ant community [1] http://mail-archives.apache.org/mod_mbox/ant-dev/201612.mbox/ajax/%3C000301d 25510%2433d37720%249b7a6560%24%40de%3E [2] http://ant.apache.org/processes.html#Reactivate%20a%20subproject%20or%20comp onent
Re: archiving EasyAnt
On 2017-01-04, Jan Matèrne (jhm) wrote: > --> Should we only place a note on the hp or completely remove them. > I prefer removing the complete homepage. I'd leave behind a note and point to the read-only SCMs so people who want to pick up development again have a starting point. > Retire: Announcement > > We have to announce the retirement of the subproject at dev@ant, > announce@apache and the Ant main page. > --> open >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. >[1] > http://mail-archives.apache.org/mod_mbox/ant-dev/201612.mbox/ajax/%3C000301d25510%2433d37720%249b7a6560%24%40de%3E >" link to http://ant.apache.org/processes.html#Reactivate%20a%20subproject%20or%20component ? > 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). > --> open, where is the repo? https://dist.apache.org/repos/dist/release/incubator/easyant/ > Retire: Free Further Resources > -- >There is a domain "easyant.org": > >Who owns that domain? What to do with these services? (shutdown ;) , | $ whois easyant.org | Domain Name: EASYANT.ORG | Domain ID: D154821074-LROR | WHOIS Server: | Referral URL: http://www.gandi.net | Updated Date: 2016-11-06T13:42:16Z | Creation Date: 2008-12-03T11:10:45Z | Registry Expiry Date: 2017-12-03T11:10:45Z | Sponsoring Registrar: Gandi SAS | Sponsoring Registrar IANA ID: 81 | Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited | Registrant ID: JB6225-GANDI | Registrant Name: Jean-Louis Boudart | ... ` Looks as if Jean-Louis could save some money at the end of this year :-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: archiving EasyAnt
Back from holiday I want to do more about archiving EasyAnt. My todo-list now is... there are some questions open I couldnt answer ... 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. Ask infra to make the repository read-only. --> open (after updating the homepage) 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. --> open 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. [1] http://mail-archives.apache.org/mod_mbox/ant-dev/201612.mbox/ajax/%3C000301d25510%2433d37720%249b7a6560%24%40de%3E " 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). --> open, where is the repo? 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? What to do with these services? (shutdown ;) - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: archiving EasyAnt
On 2016-12-13, Jan Matèrne (jhm) wrote: > - Gump: it seems, that there is no buildjob for EA > https://svn.apache.org/viewvc/gump/metadata/profile/gump.xml?view=markup > @Stefan: as our Gump master ;) please check True, EasyAnt has never been added to Gump. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
archiving EasyAnt
The vote about archiving EasyAnt passed [1]. So according to [2] the todo list is: Retire: Version Control --- Most of our source code is in git, only "site" and "sandbox" use subversion. --> only git for sources. Homepage in svn. We place a marker RETIRED_PROJECT file on the top level. --> done (will commit that after deleting the build jobs) Add a note at the top of a README file as well so it is immediately visible to people browsing the github mirror. --> done, dito Include a link to this page for a possible future reactivation and a link to the vote result. --> done Ask infra to make the repository read-only. --> open 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 Retire: Mailing List If the subproject/component has its own mailing list we have to close this. We should send a final email. --> no mailing list; used dev|us...@ant.ao Retire: Announcement We have to announce the retirement of the subproject at dev@ant, announce@apache and the Ant main page. --> open Retire: Build Jobs -- All build jobs on Jenkins@Apache, TeamCity and Gump have to be deleted. - Jenkins: deleted "EasyAnt" (standard build job), updated http://ant.apache.org/nightlies.html - TeamCity: no build jobs there - Gump: it seems, that there is no buildjob for EA https://svn.apache.org/viewvc/gump/metadata/profile/gump.xml?view=markup @Stefan: as our Gump master ;) please check Retire: Homepage Add the retirement to the archive-page. --> done 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). --> open Retire: Free Further Resources -- Maybe a subproject locks further resources (update-site, ...). So we have to unblock them. --> open: I am not aware of any resources. Someone else? Jan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: VOTE Retire EasyAnt subproject - RESULT
The vote about archiving EasyAnt starts on 05.December 2016 [1]. The result is: * binding votes +1: Jan, Stefan, Nicolas, Conor, Jean-Louis, Dominique 0: -- -1: -- * non binding votes +1: -- 0: -- -1: -- The vote passed and EasyAnt including all its subcomponents will be archived according to the specified process [2]. [1] http://mail-archives.apache.org/mod_mbox/ant-dev/201612.mbox/ajax/%3C000e01d24ec5%24dfd88ac0%249f89a040%24%40de%3E [2] http://ant.apache.org/processes.html Jan - 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 On Wed, Dec 7, 2016 at 8:14 AM, Jean-Louis Boudart < jeanlouis.boud...@gmail.com> wrote: > +1 > > 2016-12-07 1:05 GMT+01:00 Conor MacNeill : > > > +1 > > > > Conor > > > > > > On 5 December 2016 at 18:04, Jan Matèrne (jhm) > 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 Retire EasyAnt subproject
+1 2016-12-07 1:05 GMT+01:00 Conor MacNeill : > +1 > > Conor > > > On 5 December 2016 at 18:04, Jan Matèrne (jhm) 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 Retire EasyAnt subproject
+1 Conor On 5 December 2016 at 18:04, Jan Matèrne (jhm) 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
Re: VOTE Retire EasyAnt subproject
+1 Nicolas > Le 5 déc. 2016 à 08:04, Jan Matèrne (jhm) a écrit : > > 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
Re: VOTE Retire EasyAnt subproject
On 2016-12-05, Jan Matèrne (jhm) wrote: > I start a vote for retiring EasyAnt and all its components: > - core > - buildtypes > - plugins > - skeletons > - tasks > - easyant4e +1 Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
VOTE Retire EasyAnt subproject
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
[GitHub] ant-easyant-core pull request #3: Fix plugin report information
Github user asfgit closed the pull request at: https://github.com/apache/ant-easyant-core/pull/3 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-easyant-core pull request #2: Upgrade Junit: fix Eclipse project classpa...
Github user asfgit closed the pull request at: https://github.com/apache/ant-easyant-core/pull/2 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-easyant-core pull request #3: Fix plugin report information
GitHub user AQuillet opened a pull request: https://github.com/apache/ant-easyant-core/pull/3 Fix plugin report information You can merge this pull request into a Git repository by running: $ git pull https://github.com/AQuillet/ant-easyant-core feature/EASYANT-77 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ant-easyant-core/pull/3.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #3 commit 276111f2ffa53e340f1b6a37eda2136ed2128a02 Author: Adrien Quillet Date: 2016-08-09T06:31:49Z Upgrade Junit: fix Eclipse project classpath https://issues.apache.org/jira/browse/EASYANT-76 commit 642d7a04b68da0f744338c17d37c58288db26348 Author: Adrien Quillet Date: 2016-08-09T07:46:14Z Merge branch 'feature/EASYANT-76' into 'develop-microej' Upgrade Junit: fix Eclipse project classpath https://issues.apache.org/jira/browse/EASYANT-76 See merge request !1 commit 8ef1021207a6353f0fbca00fa8787b765ea2fd42 Author: Adrien Quillet Date: 2016-08-10T06:26:30Z Fix plugin report information https://issues.apache.org/jira/browse/EASYANT-77 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-easyant-core pull request #2: Upgrade Junit: fix Eclipse project classpa...
GitHub user AQuillet opened a pull request: https://github.com/apache/ant-easyant-core/pull/2 Upgrade Junit: fix Eclipse project classpath https://issues.apache.org/jira/browse/EASYANT-76 You can merge this pull request into a Git repository by running: $ git pull https://github.com/AQuillet/ant-easyant-core feature/EASYANT-76 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ant-easyant-core/pull/2.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2 commit 276111f2ffa53e340f1b6a37eda2136ed2128a02 Author: Adrien Quillet Date: 2016-08-09T06:31:49Z Upgrade Junit: fix Eclipse project classpath https://issues.apache.org/jira/browse/EASYANT-76 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-easyant-core pull request: Compliance with J2SE 1.7
Github user asfgit closed the pull request at: https://github.com/apache/ant-easyant-core/pull/1 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[GitHub] ant-easyant-core pull request: Compliance with J2SE 1.7
GitHub user AQuillet opened a pull request: https://github.com/apache/ant-easyant-core/pull/1 Compliance with J2SE 1.7 https://issues.apache.org/jira/browse/EASYANT-75 You can merge this pull request into a Git repository by running: $ git pull https://github.com/AQuillet/ant-easyant-core master Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ant-easyant-core/pull/1.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #1 commit 7370ea0f2657ac1f73383de92cd5e7e778785855 Author: Adrien Quillet Date: 2015-09-23T07:37:46Z Compliance with J2SE 1.7 https://issues.apache.org/jira/browse/EASYANT-75 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: Generating EasyAnt website
BTW here some issues regarding the EA website https://issues.apache.org/jira/browse/EASYANT-66 https://issues.apache.org/jira/browse/EASYANT-74 https://issues.apache.org/jira/browse/EASYANT-63 Jan > -Ursprüngliche Nachricht- > Von: Jan Matèrne (jhm) [mailto:apa...@materne.de] > Gesendet: Freitag, 23. Januar 2015 11:55 > An: 'Ant Developers List' > Betreff: AW: Generating EasyAnt website > > I'll tried that also > > $ easyant publish-shared > > But xooki requires Java 1.6 and I failed to get it running ... > > On Windows cmd.exe with Java 1.6: > xooki:generate: > [xooki:generate] processing 65 source files... > [generate] script file ./sources/xooki/xooki.js is not found > [generate] Result: 11 ...lots of them... > > > On git bash I failed to change from 1.8 to 1.6 :( > > I did some adds to the README. If you could have a look at that if you > have that running ... > > > Jan > > > > -Ursprüngliche Nachricht- > > Von: Jean-Louis Boudart [mailto:jeanlouis.boud...@gmail.com] > > Gesendet: Freitag, 23. Januar 2015 08:48 > > An: Ant Developers List > > Betreff: 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”. > > > > > 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 > > : > > > > > 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/ > > > - > 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
AW: Generating EasyAnt website
I'll tried that also $ easyant publish-shared But xooki requires Java 1.6 and I failed to get it running ... On Windows cmd.exe with Java 1.6: xooki:generate: [xooki:generate] processing 65 source files... [generate] script file ./sources/xooki/xooki.js is not found [generate] Result: 11 ...lots of them... On git bash I failed to change from 1.8 to 1.6 :( I did some adds to the README. If you could have a look at that if you have that running ... Jan > -Ursprüngliche Nachricht- > Von: Jean-Louis Boudart [mailto:jeanlouis.boud...@gmail.com] > Gesendet: Freitag, 23. Januar 2015 08:48 > An: Ant Developers List > Betreff: 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”. > > 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 > : > > > 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/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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”. 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 : > 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/
Generating EasyAnt website
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
Re: Build failed in Jenkins: EasyAnt #175
Thanks ! 2014-06-18 8:14 GMT+02:00 Jan Matèrne (jhm) : > 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/
AW: Build failed in Jenkins: EasyAnt #175
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
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
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 ? 2014-06-17 21:25 GMT+02:00 Apache Jenkins Server : > See <https://builds.apache.org/job/EasyAnt/175/changes> > > Changes: > > [jeanlouis.boudart] Add xooki as git submodule > > -- > [...truncated 648 lines...] > [java] [ivy:install] :: install resolution report :: > [java] [ivy:install] :: resolution report :: resolve 0ms :: artifacts > dl 1ms > [java] > - > [java] | |modules|| > artifacts | > [java] | conf | number| search|dwnlded|evicted|| > number|dwnlded| > [java] > - > [java] | default | 1 | 0 | 0 | 0 || 1 > | 0 | > [java] > - > [java] [ivy:install] :: installing > org.apache.easyant.plugins#phases-std#*;0.9 :: > [java] [ivy:install] found > org.apache.easyant.plugins#phases-std;0.9 to install: adding to the list > [java] [ivy:install] :: resolving dependencies :: > [java] [ivy:install] found > org.apache.easyant.plugins#phases-std;0.9 in apache-easyant-plugins > [java] [ivy:install] :: downloading artifacts to cache :: > [java] [ivy:install] :: installing in core :: > [java] [ivy:install] published phases-std to < > https://builds.apache.org/job/EasyAnt/ws/target/main/classes/repository/core/org.apache.easyant.plugins/phases-std/0.9/phases-std.ant > > > [java] [ivy:install] published ivy to < > https://builds.apache.org/job/EasyAnt/ws/target/main/classes/repository/core/org.apache.easyant.plugins/phases-std/0.9/phases-std.ivy > > > [java] [ivy:install] :: install resolution report :: > [java] [ivy:install] :: resolution report :: resolve 0ms :: artifacts > dl 1ms > [java] > - > [java] | |modules|| > artifacts | > [java] | conf | number| search|dwnlded|evicted|| > number|dwnlded| > [java] > - > [java] | default | 1 | 0 | 0 | 0 || 1 > | 0 | > [java] > - > [java] [ivy:install] :: installing > org.apache.easyant.plugins#resources-std#*;0.9 :: > [java] [ivy:install] found > org.apache.easyant.plugins#resources-std;0.9 to install: adding to the list > [java] [ivy:install] :: resolving dependencies :: > [java] [ivy:install] found > org.apache.easyant.plugins#resources-std;0.9 in apache-easyant-plugins > [java] [ivy:install] :: downloading artifacts to cache :: > [java] [ivy:install] :: installing in core :: > [java] [ivy:install] published resources-std to < > https://builds.apache.org/job/EasyAnt/ws/target/main/classes/repository/core/org.apache.easyant.plugins/resources-std/0.9/resources-std.ant > > > [java] [ivy:install] published ivy to < > https://builds.apache.org/job/EasyAnt/ws/target/main/classes/repository/core/org.apache.easyant.plugins/resources-std/0.9/resources-std.ivy > > > [java] [ivy:install] :: install resolution report :: > [java] [ivy:install] :: resolution report :: resolve 0ms :: artifacts > dl 1ms > [java] > - > [java] | |modules|| > artifacts | > [java] | conf | number| search|dwnlded|evicted|| > number|dwnlded| > [java] > - > [java] | default | 1 | 0 | 0 | 0 || 1 > | 0 | > [java] > - > [java] [ivy:install] :: installing > org.apache.easyant.plugins#run-java#*;0.9 :: > [java] [ivy:install] found > org.apache.easyant.plugins#run-java;0.9 to install: adding to the list > [java] [ivy:install] :: resolving dependencies :: > [java] [ivy:install] found > org.apache.easyant.plugins#run-java;0.9
AW: svn commit: r1603069 - /ant/site/easyant/sources/Sourcerepository.html
Not sure if there is something to generate with xooki ... Jan > Log: > repo changed to git > > Modified: > ant/site/easyant/sources/Sourcerepository.html > > --- ant/site/easyant/sources/Sourcerepository.html (original) > +++ ant/site/easyant/sources/Sourcerepository.html Tue Jun 17 06:38:38 > 2014 > @@ -25,7 +25,7 @@ > > Subversion repository > > -You can get the latest source code of EasyAnt from Apache Subversion > repository at https://svn.apache.org/repos/asf/ant/easyant/ > +You can get the latest source code of EasyAnt from Apache Git > repository at https://git-wip-us.apache.org/repos/asf/ant-easyant- > core.git - 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) : > 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/
EasyAnt - status
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
Re: easyant eclipse plugin
Le 19 nov. 2013 à 11:16, Richard C Hidalgo Lorite a écrit : > hi, is there an eclipse plugin for easyant? There is one, but it never has been released. Its source can be found there: https://svn.apache.org/repos/asf/ant/easyant/easyant4e/trunk Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
easyant eclipse plugin
hi, is there an eclipse plugin for easyant? if not, is there a set of standard ant libraries with typical targets that one can use with ivyide eclipse plugin? thx in advance
Re: Easyant - Plugin conflict management
On Wed, Aug 28, 2013 at 11:19 AM, Jean-Louis Boudart wrote: > My answers below > > > 2013/8/26 Dridi Boukelmoune > >> >> 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". > Forgot about that. >> >> 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 :). I agree on the fact this can easily become a classloader hell, but my concern is the dependency hell. Again, I have no answer to your question, I'm just asking more questions :) > 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. I think I lack context to understand this one. > -- > Jean Louis Boudart > Independent consultant > Apache EasyAnt commiter http://ant.apache.org/easyant/ Best Regards, Dridi - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Easyant - Plugin conflict management
My answers below 2013/8/26 Dridi Boukelmoune > >> 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 also forgot one comparison. >From my understaning, please correct me if I'm wrong: - maven plugins are bound to phases, lifecycles specify the order of the phases - easyant plugins are bound to extension points, the order derives from dependencies between the extension points - maven solves (plugin) dependencies through a chain of inheritance - maven fills by default the lifecycle with goals depending on the module packaging - easyant can fill the lifecycle with build-type plugins (to make things easier) Now Jean-Louis said: >>> >>>> 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). What bugs me, is the fact that changing package-jar's version could change my compile-java's version. This is just a caricature, but for me the former creates a zip while the latter invokes javac ; they should be unrelated. If both package-jar and compile-java with diverging versions conflict on a dependency, they should each get the one they need. I take the plexus-utils dependency as an example, because a lot of maven plugins use it. So when I change my maven-package-plugin version, it has no effect AFAIK on my maven-compiler-plugin. Maven makes it hard to customize the lifecycle, so I've never met someone willing to do so. My point of view in a nutshell: - "build-type" plugins help define easily the lifecycle - "regular" plugins should not drag other plugins Now what happens when you have several build-types (eg. a polyglot project) ? I'd tend to think that a build-type should override previous build-types (eg. package-jar needed by both java and scala builds). Best Regards, Dridi On Tue, Aug 27, 2013 at 8:22 AM, Dridi Boukelmoune wrote: > Hi Martin, > > I believe one of my comments must have offended you and maybe others. > This was a reference to the shitty-maven-plugin, which made me laugh > the first time I saw it. For anything other than Maven I would have > said something along "and does a poor job". I should have written > "shitty[x]" and put my reference to make it obvious, I suppose only > plugin writers tend to know this one. > > On Tue, Aug 27, 2013 at 12:04 AM, Martin Gainty wrote: >> you never looked at plugin-management > > Yes I know, use and encourage others to use it at work. > >> understanding what you're criticising before you write a commentary will >> lend veracity to your statements > > You are right about understanding, this is why I said "I think I've > observed". However I use plugin-management to make modules > dependencies converge (in a multi-module project or let's say > company-wide with a common parent pom). So that for instance all my > jar modules use the same version/configuration of the *implicitly > declared* compiler plugin. > > But in my comment I'm not talking about plugin-management, I'm talking > about plugin dependencies. > > From the first few seconds of a "mvn -X clean verify" build: > [DEBUG] Populating class realm > plugin>org.apache.maven.plugins:maven-clean-plugin:2.4.1 > [DEBUG] Included: org.apache.maven.plugins:maven-clean-plugin:jar:2.4.1 > [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:2.0.5 > [DEBUG] Excluded: org.apache.maven:maven-plugin-api:jar:2.0.6 > [DEBUG] Configuring mojo > org.apache.maven.plugins:maven-clean-plugin:2.4.1:clean from plugin > realm ClassRealm[plugin>org.apache.maven.plugins:maven-clean-plugin:2.4.1, > parent: sun.misc.Launcher$AppClassLoader@e1641c0] > > [DEBUG] Populating class realm > plugin>org.apache.maven.plugins:maven-surefire-plugin:2.12 > [DEBUG] Included: org.apache.maven.plugins:maven-surefire-plugin:jar:2.12 > [DEBUG] Included: org.apache.maven.surefire:surefire-booter:jar:2.12 > [DEBUG] Included: org.apache.maven.surefire:surefire-api:jar:2.12 > [DEBUG] Included: org.apache.maven.surefire:maven-surefire-common:jar:2.12 > [DEBUG] Included: > org.apache.maven.shared:maven-common-artifact-filters:jar:1.3 > [DEBUG] Included: org.codehaus.plexus:plexus-utils:jar:3.0 > [DEBUG] Included: org.apache.maven.reporting:maven-reporting-api:jar:2.0.9 &
Re: Easyant - Plugin conflict management
ionen und entfaltet keine rechtliche > Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen > wir keine Haftung fuer den Inhalt uebernehmen. > > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le > destinataire prévu, nous te demandons avec bonté que pour satisfaire informez > l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci > est interdite. Ce message sert à l'information seulement et n'aura pas > n'importe quel effet légalement obligatoire. Étant donné que les email > peuvent facilement être sujets à la manipulation, nous ne pouvons accepter > aucune responsabilité pour le contenu fourni. > > > > >> From: dridi.boukelmo...@zenika.com >> Date: Mon, 26 Aug 2013 20:31:32 +0200 >> Subject: Re: Easyant - Plugin conflict management >> To: dev@ant.apache.org >> >> Hi, >> >> This is my first post on this mailing list, I used to lurk in the >> previous easant ML and even answer sometimes. >> >> In this thread I see several points and one of them looks like a >> non-issue to me. Please forgive my heresy when I use maven as an >> example. >> >> On Tue, Aug 20, 2013 at 6:50 PM, Nicolas Lalevée >> wrote: >> > >> > Le 20 août 2013 à 14:22, Jean-Louis Boudart >> > a écrit : >> > >> >> 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. >> > >> > This seems strange to me. Do you have an idea why ? >> >> I believe he meant this could *improve* performances by sharing a >> single global resolve between all plugins (or something like that). >> >> >> 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. >> >> >> 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 >> ? >> >> At the very least, I like the idea of a single global resolve. Even >> though I understand the benefits of a lazy resolution/download, I >> don't see this as a problem with today's average bandwidth and disk >> space to get every thing needed by a build in a single go. I tend to >> work offline and I hate when I discover in the train that I'm missing >> a dependency :) >> >> >> You can check ResolvePlugins and ImportDeferred class in trunk if you want >> >> to see concrete stuff. >> > >> > I usually do a very quick review of the code to keep me informed of what >> > is going on and see if nothing bug me, and as always, it seems great. But >> > I need to get into this more deeply to see how it really works. >> > >> > Nicolas >> > >> >> Best Regards, >> Dridi >> >> [1] it's just that I don't like it :p >> >> >> >> >> >> >> >> >> >> >> 2013/8/17 Nicolas Lalevée >> >> >> >>> Long ove
RE: Easyant - Plugin conflict management
you never looked at plugin-management understanding what you're criticising before you write a commentary will lend veracity to your statements http://maven.apache.org/pom.html#Plugin_Management Martin Gainty __ Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopife ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > From: dridi.boukelmo...@zenika.com > Date: Mon, 26 Aug 2013 20:31:32 +0200 > Subject: Re: Easyant - Plugin conflict management > To: dev@ant.apache.org > > Hi, > > This is my first post on this mailing list, I used to lurk in the > previous easant ML and even answer sometimes. > > In this thread I see several points and one of them looks like a > non-issue to me. Please forgive my heresy when I use maven as an > example. > > On Tue, Aug 20, 2013 at 6:50 PM, Nicolas Lalevée > wrote: > > > > Le 20 août 2013 à 14:22, Jean-Louis Boudart a > > écrit : > > > >> 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. > > > > This seems strange to me. Do you have an idea why ? > > I believe he meant this could *improve* performances by sharing a > single global resolve between all plugins (or something like that). > > >> 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. > > >> 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 > ? > > At the very least, I like the idea of a single global resolve. Even > though I understand the benefits of a lazy resolution/download, I > don't see this as a problem with today's average bandwidth and disk > space to get every thing needed by a build in a single go. I tend to > work offline and I hate when I discover in the train that I'm missing > a dependency :) > > >> You can check ResolvePlugins and ImportDeferred class in trunk if you want > >> to see concrete stuff. > > > > I usually do a very quick review of the code to keep me informed of what is > > going on and see if nothing bug me, and as always, it seems great. But I > > need to get into this more deeply to see how it really works. > > > > Nicolas > > > > Best Regards, > Dridi > > [1] it's just that I don&#
Re: Easyant - Plugin conflict management
Hi, This is my first post on this mailing list, I used to lurk in the previous easant ML and even answer sometimes. In this thread I see several points and one of them looks like a non-issue to me. Please forgive my heresy when I use maven as an example. On Tue, Aug 20, 2013 at 6:50 PM, Nicolas Lalevée wrote: > > Le 20 août 2013 à 14:22, Jean-Louis Boudart a > écrit : > >> 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. > > This seems strange to me. Do you have an idea why ? I believe he meant this could *improve* performances by sharing a single global resolve between all plugins (or something like that). >> 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. >> 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 ? At the very least, I like the idea of a single global resolve. Even though I understand the benefits of a lazy resolution/download, I don't see this as a problem with today's average bandwidth and disk space to get every thing needed by a build in a single go. I tend to work offline and I hate when I discover in the train that I'm missing a dependency :) >> You can check ResolvePlugins and ImportDeferred class in trunk if you want >> to see concrete stuff. > > I usually do a very quick review of the code to keep me informed of what is > going on and see if nothing bug me, and as always, it seems great. But I need > to get into this more deeply to see how it really works. > > Nicolas > Best Regards, Dridi [1] it's just that I don't like it :p >> >> >> >> >> 2013/8/17 Nicolas Lalevée >> >>> Long overdue response. >>> >>> Le 3 août 2013 à 13:33, Jean-Louis Boudart >>> 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). >>>> >>>> >>>> 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 or 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. >>>> >>>> >>>> If organisation attribute is not specified on aliases default one will >>> be >>>> used. >>
Re: Easyant - Plugin conflict management
Le 20 août 2013 à 14:22, Jean-Louis Boudart a écrit : > 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. This seems strange to me. Do you have an idea why ? > Point 2 : Even if there is no much activity, i suggest to keep backward > compatibility fine for me. > 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. > You can check ResolvePlugins and ImportDeferred class in trunk if you want > to see concrete stuff. I usually do a very quick review of the code to keep me informed of what is going on and see if nothing bug me, and as always, it seems great. But I need to get into this more deeply to see how it really works. Nicolas > > > > > 2013/8/17 Nicolas Lalevée > >> Long overdue response. >> >> Le 3 août 2013 à 13:33, Jean-Louis Boudart >> 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). >>> >>> >>> 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 or 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. >>> >>> >>> 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 >>> >> revision="1.0"/> >>> >>> The compile java ant script will import the resolved plugin >>> >> module="abstract-compile"/> >>> >>> Note that i'm not fixed yet with the task name. Any suggestion (even for >>> alliases are welcome). >>> >>> To maintain backwar
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 > Long overdue response. > > Le 3 août 2013 à 13:33, Jean-Louis Boudart > 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). > > > > > > 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 or 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. > > > > > > 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 > > > revision="1.0"/> > > > > The compile java ant script will import the resolved plugin > > > 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 tas
Re: Easyant - Plugin conflict management
Long overdue response. Le 3 août 2013 à 13:33, Jean-Louis Boudart 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). > > > 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 or 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. > > > 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 > revision="1.0"/> > > The compile java ant script will import the resolved plugin > 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 this is a larger topic which has bugging me recently. The way we use the ivy.xml is generally either to tight or insecure. For instance when using version ranges in an ivy.xml, since the content of the repository is expected to change over time, then the resolve may change over time since new versions might fit the range. Range makes things unreliable over time, so often I restrict myself to not use any range. But it's kind of a shame to not use ranges in a dependency manager. I continued experimenting with the OSGi mapping in Ivy. And the OSGi version semantics are very loose. It is because it represents what versions of software it is compatible with, not the versions we will be using in your specific unit test or application. So relying on OSGi manifest to resolve dependencies is not safe at all. That's why I implemented the fixdeps [1] task.
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). 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 or 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. 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 The compile java ant script will import the resolved plugin 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: Evaluating Bintray as a distribution platform for easyant plugins
Many many thanks for taking the time to explain it in so much detail, Jean-Louis. I now understand that plugins, buildtypes and skeletons are not well suited to be distributed in a Maven formatted, POM enforcing environment like Maven Central No objections from me again using bintray, you've convinced me that Macen Central would be a bad fit and something else is needed. On 2013-05-09, Jean-Louis Boudart wrote: > 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. Understood. And I don't see any reason why bintray would be worse a choice than a self-hosted website. > 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/ First of all, we'd still distribute all Apache releases via dist.apache.org, but there isn't any reason why they couldn't be distributed via different channels as well - just like Maven Central is a different channel or CPAN or gem servers are. I'm not quite sure why you'd want to have the separate internal repositories. Is this so people can stick to Apache compatible stuff only if they really want to - to spare them the time to read the license itself? If the distribution point you are talking about is outside of the ASF there is nobody forcing you to separate stuff, of course you can do so. Thanks again Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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 > 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) > > > >> 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, > >>> > >>> > >>> An
Re: Evaluating Bintray as a distribution platform for easyant plugins
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) > >> 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" >>>> 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" >>>>> 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/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Evaluating Bintray as a distribution platform for easyant plugins
On 2013-05-03, Jean-Louis Boudart wrote: > No objections either if both Apache & non Apache plugins are on > bintray ? :p Then I must admit I misunderstood your proposal. Why do we need a separate distribution point for ASF released EasyAnt plugins? Maybe you need to enlighten those of us who haven't followed EasyAnt what kind of service you intend to offer. :-) I thought it would be a Maven layout compatible repository that could be used side by side with Maven Central. It seems I'm wrong. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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) > 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" > > > 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" > > >> 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/
AW: Evaluating Bintray as a distribution platform for easyant plugins
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" > > 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" > >> 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
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" 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" >> 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/ >>> >> - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: AW: Evaluating Bintray as a distribution platform for easyant plugins
No objections? :p Le 29 avr. 2013 20:59, "Jean-Louis Boudart" 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" > 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/ >> >
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" 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/ >
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: Evaluating Bintray as a distribution platform for easyant plugins
On 2013-04-29, Jan Matèrne (jhm) wrote: >> 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/ > Oh - I mean that only for "ASF plugins". +1 on that, and I don't think Jean Louis disagrees with that, at least I didn't read it that way. He's suggesting to use bintray for plugins that cannot be released as Apache plugins for license reasons (Sonar or Checkstyle use incompatible licenses for example). Personally I'm +1 on the idea itself but I don't do the work myself and so would let the people who write the plugins make the decision and abstain myself. :-) Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: Evaluating Bintray as a distribution platform for easyant plugins
> > 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. > > 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/ Oh - I mean that only for "ASF plugins". There is (of course) the possibility of hosting plugins outside the ASF. But if possible I would host them at ASF so the community has one "connection point", especially if EasyAnt is just migrated to ASF. Jan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
AW: Evaluating Bintray as a distribution platform for easyant plugins
> 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. 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/ > They also offers download statistics which could be interresting for us. Not sure about getting statistics from Nexus. But should be possible ... (maybe we have to ask #infra) > 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? > 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? > 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. 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 Jan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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 http://dl.bintray.com/content/easyant/community-plugins/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]"/> http://dl.bintray.com/content/easyant/community-plugins/[organisation]/[module]/[revision]/[type]s/[artifact].[ext]"/> 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: Some feedback on EasyAnt
Done on trunk Le 17 avr. 2013 18:32, "Xavier Hanin" 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
Xavier- in Maven if you have no Junit tests located in .\src\test folf then all test (test-scoped) dependencies are skipped the same behaviour should be emulated in 'EasyAnt' My 2 cents Martin __ Note de déni et de confidentialitéCe message est confidentiel et peut être privilégié. Si vous n'êtes pas le destinataire prévu, nous te demandons avec bonté que pour satisfaire informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est interdite. Ce message sert à l'information seulement et n'aura pas n'importe quel effet légalement obligatoire. Étant donné que les email peuvent facilement être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité pour le contenu fourni. > Date: Wed, 17 Apr 2013 18:32:07 +0200 > Subject: Re: Some feedback on EasyAnt > From: xavier.ha...@gmail.com > To: dev@ant.apache.org > > 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
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
On Mon, Apr 15, 2013 at 9:13 PM, Jean-Louis Boudart < jeanlouis.boud...@gmail.com> wrote: > Hi Xavier, > > Thanks for your feedback ! > [...] > > > > - 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. > Yes, it would really be nice, and sources are pretty much self explanatory, so it could be enough to start. Maybe only a link to the plugins repo to browse the source online could be a good start. > > > > - 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 ? > Yes, I will, but it's very basic. It's part of another project I'm working on, I'll keep you posted when I release it in open source. 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 > Hi Xavier, > > Thanks for your feedback ! > > > 2013/4/15 Xavier Hanin > >> >> 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 >> for 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 > > 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 > for 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/
Some feedback on EasyAnt
Hi there, It's been a while :-) 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 for 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" - 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). - 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" 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. 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. Keep up the good work! Xavier -- Xavier Hanin - 4SH France - http://www.4sh.fr/ BordeauxJUG creator - http://www.bordeauxjug.org/ Apache Ivy Creator - http://ant.apache.org/ivy/
Re: EasyAnt is graduating
As far as I can tell, the status of EasyAnt on the incubator pages are up to date, it is not listed anymore as an Incubator project. There was still things in the svn, kept because we needed to wait for the site to be moved. I have just completely deleted it cf r1461470. I also just put in place a redirection of http://incubator.apache.org/easyant to http://ant.apache.org/easyant cf r1461474. Again I am not familiar with the publishing process of the incubator site. So it's not active yet. The last resource standing is the published release. But it needs to stay there until we have a new release here. Nicolas Le 27 mars 2013 à 10:30, Jean-Louis Boudart a écrit : > Do you mean the incubator logo on easyant site? or stuff at > http://incubator.apache.org/projects/easyant.html ? > > > 2013/3/27 Stefan Bodewig > >> On 2013-03-27, Jean-Louis Boudart wrote: >> >>> PS: i think we forgot setuping redirection from incubator.a.o/easyant to >>> ant.a.o/easyant. I will fix this today >> >> There may be some cleanup to do inside the Incubator site itself as >> well. >> >> 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/ - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: EasyAnt is graduating
Do you mean the incubator logo on easyant site? or stuff at http://incubator.apache.org/projects/easyant.html ? 2013/3/27 Stefan Bodewig > On 2013-03-27, Jean-Louis Boudart wrote: > > > PS: i think we forgot setuping redirection from incubator.a.o/easyant to > > ant.a.o/easyant. I will fix this today > > There may be some cleanup to do inside the Incubator site itself as > well. > > 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/
Re: EasyAnt is graduating
On 2013-03-27, Jean-Louis Boudart wrote: > PS: i think we forgot setuping redirection from incubator.a.o/easyant to > ant.a.o/easyant. I will fix this today There may be some cleanup to do inside the Incubator site itself as well. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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" a écrit : > > Le 16 mars 2013 à 01:39, Nicolas Lalevée 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: EasyAnt is graduating
On 2013-03-23, Nicolas Lalevée wrote: > We need to give r/w rights to Jérôme Benois (jbenois) and Siddhartha > Purkayastha (kpsiddharth). Done Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: EasyAnt is graduating
Le 16 mars 2013 à 01:39, Nicolas Lalevée 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
AW: EasyAnt is graduating
> There is nothing in Gump about EasyAnt Should it be? Jan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: EasyAnt is graduating
Le 16 mars 2013 à 09:47, Jan Matèrne (jhm) a écrit : > 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. Nicolas > > Jan > > >> -Ursprüngliche Nachricht- >> Von: Stefan Bodewig [mailto:bode...@apache.org] >> Gesendet: Samstag, 16. März 2013 06:49 >> An: dev@ant.apache.org >> Betreff: Re: EasyAnt is graduating >> >> On 2013-03-16, Nicolas Lalevée wrote: >> >>> Finally ! We're there ! >> >> Welcome. >> >>> * 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. >>> We'll give write rights to EasyAnt committers on the entire Ant svn >> tree. >> >>> * 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. 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/.htacce >>> ss) >>> - change the svnpubsub >> >>> * 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. >> >>> * 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 >> >>> Unless there is some objections, I'll start that sometime next week. >> >> +1 to all of your suggestions. >> >> 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
AW: EasyAnt is graduating
Maybe some changes in the Gump metadata and Jenkins jobs? Jan > -Ursprüngliche Nachricht- > Von: Stefan Bodewig [mailto:bode...@apache.org] > Gesendet: Samstag, 16. März 2013 06:49 > An: dev@ant.apache.org > Betreff: Re: EasyAnt is graduating > > On 2013-03-16, Nicolas Lalevée wrote: > > > Finally ! We're there ! > > Welcome. > > > * 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. > > We'll give write rights to EasyAnt committers on the entire Ant svn > tree. > > > * 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. 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/.htacce > > ss) > > - change the svnpubsub > > > * 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. > > > * 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 > > > Unless there is some objections, I'll start that sometime next week. > > +1 to all of your suggestions. > > 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: EasyAnt is graduating
On 2013-03-16, Nicolas Lalevée wrote: > Finally ! We're there ! Welcome. > * 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. > We'll give write rights to EasyAnt committers on the entire Ant svn tree. > * 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. 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) > - change the svnpubsub > * 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. > * 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 > Unless there is some objections, I'll start that sometime next week. +1 to all of your suggestions. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
EasyAnt is graduating
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. We'll give write rights to EasyAnt committers on the entire Ant svn tree. * 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. 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) - change the svnpubsub * 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. * 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 Unless there is some objections, I'll start that sometime next week. Nicolas - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [RESULT][VOTE] Accept EasyAnt as a subproject - take 2
Congratulations EasyAnt, Antoine On Mar 6, 2013, at 2:34 PM, Nicolas Lalevée wrote: > I count: > - 5 binding +1 > - 1 non-binding +1 > > The proposition is accepted. > > Thank you all. > > We'll go now to the incubator mailing lists to clear things up. > > Nicolas > > Le 27 févr. 2013 à 19:44, Nicolas Lalevée a > écrit : > >> 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 > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
[RESULT][VOTE] Accept EasyAnt as a subproject - take 2
I count: - 5 binding +1 - 1 non-binding +1 The proposition is accepted. Thank you all. We'll go now to the incubator mailing lists to clear things up. Nicolas Le 27 févr. 2013 à 19:44, Nicolas Lalevée a écrit : > 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
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
A great big +1. With Ivy, we decided that having a separate users mailing list made sense but that we were better off having a single developers mailing list for both projects. I suggest we do the same again with EasyAnt assuming the vote is successful this time, unless the EasyAnt committers would prefer to remain separate. On 27/02/2013 10:44 AM, Nicolas Lalevée wrote: So, should we accept EasyAnt as a subproject ? Please, cast your votes: [ ] +1, I accept [ ] +0, OK, but…. [ ] -1, I disapprove, because…. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
RE: [VOTE] Accept EasyAnt as a subproject - take 2
Hi, that's great news! We will we very happy to provide you with feedback. Best Regards, Tim PS: Odd thing aside: I worked on a company intern concept to modularize Ant builds of software enriched with Ivy-meta data for a few months now (without tying us to Maven). Not knowing that there was EasyAnt and working on the basis of only Ant and Ivy I came to very similar conclusions regarding the design. Some of the technical details are even identical! - like providing paths to artifacts of a build module's dependencies in Ant paths like "acme#foo.foo.properties.file" to use them in Ant imports/includes. And I already stumbled upon the extension you brought into Ant and Ivy and was going to rely on them, not knowing where they actually came from. I'm very pleased to see, that someone has shared my thoughts and brought them a lot further :-) > -Original Message- > From: Jean-Louis Boudart [mailto:jeanlouis.boud...@gmail.com] > Sent: Donnerstag, 28. Februar 2013 12:05 > To: Ant Developers List > Subject: 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 > > > 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?Fromskimmi > ng 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
AW: [VOTE] Accept EasyAnt as a subproject - take 2
+1 Would be fine to bring this incubation to an end. Jan > -Ursprüngliche Nachricht- > Von: Antoine Levy Lambert [mailto:anto...@gmx.de] > Gesendet: Donnerstag, 28. Februar 2013 00:18 > An: Ant Developers List > Betreff: Re: [VOTE] Accept EasyAnt as a subproject - take 2 > > +1 Antoine > On Feb 27, 2013, at 1:44 PM, Nicolas Lalevée wrote: > > > 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 - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
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 > 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
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?From skimming 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
Re: [VOTE] Accept EasyAnt as a subproject - take 2
+1 Maarten From: Nicolas Lalevée To: Ant Developers List Sent: Wednesday, February 27, 2013 7:44 PM 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
Re: [VOTE] Accept EasyAnt as a subproject - take 2
+1 Nicolas Le 27 févr. 2013 à 19:44, Nicolas Lalevée a écrit : > 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
Re: [VOTE] Accept EasyAnt as a subproject - take 2
+1 Antoine On Feb 27, 2013, at 1:44 PM, Nicolas Lalevée wrote: > 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
Re: [VOTE] Accept EasyAnt as a subproject - take 2
[x] +1, I accept 2013/2/27 Nicolas Lalevée > 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/
[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
Re: [RESULT][VOTE] Accept EasyAnt as a subproject
Le 15 août 2012 à 23:08, Maarten Coene a écrit : > Nicolas, > > Maybe we could vote again later when there are more people around? > I haven't been online for about a month, that's why you didn't get my vote. Yes, this is what have been discussed on an easyant mailing list, we'll try later after showing some nice activity from the easyant committers. Nicolas > > Maarten > > > > > > From: Nicolas Lalevée > To: Ant Developers List > Sent: Thursday, July 26, 2012 2:41 PM > Subject: [RESULT][VOTE] Accept EasyAnt as a subproject > > I am closing the vote. I count 2 binding +1, 1 non binding +1 > > The proposition failed to be accepted. > > Further discussion will happen on easyant mailing lists. > > Nicolas > > Le 11 juil. 2012 à 10:48, Nicolas Lalevée a écrit : > >> EasyAnt is a project based on Ant and Ivy which is in incubation under our >> "sponsoring". >> >> I kind of misunderstood the "sponsoring". I was thinking that it was >> implying that EasyAnt will become part of the Ant project. It doesn't bylaw. >> We just cleared it out with the EasyAnt community. So let's clear it out >> with this vote for the Ant PMC. >> I also thought that EasyAnt should have a classical incubation period, doing >> release and growing a community. But it has no sense since if EasyAnt is >> accepted as a subproject of Ant, the Ant PMC will be responsible for EasyAnt >> code and releases. >> >> So if we accept EasyAnt, the code will be imported, committers added. But >> releases should be voted by us. I'm the only active EasyAnt committer which >> is also an Ant PMC member. This means that other Ant PMC member should be >> involved so that things can roll. We have been managing that with Ivy and >> IvyDE, but this is something that should have in mind while voting. Also >> note that it would somehow resolve itself it some EasyAnt developer become >> part of the Ant PMC, some of them have already wrote some nice patches on >> Ant and Ivy :) >> >> So, should we accept EasyAnt as a subproject ? >> >> >> 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
Re: [RESULT][VOTE] Accept EasyAnt as a subproject
Nicolas, Maybe we could vote again later when there are more people around? I haven't been online for about a month, that's why you didn't get my vote. Maarten From: Nicolas Lalevée To: Ant Developers List Sent: Thursday, July 26, 2012 2:41 PM Subject: [RESULT][VOTE] Accept EasyAnt as a subproject I am closing the vote. I count 2 binding +1, 1 non binding +1 The proposition failed to be accepted. Further discussion will happen on easyant mailing lists. Nicolas Le 11 juil. 2012 à 10:48, Nicolas Lalevée a écrit : > EasyAnt is a project based on Ant and Ivy which is in incubation under our > "sponsoring". > > I kind of misunderstood the "sponsoring". I was thinking that it was implying > that EasyAnt will become part of the Ant project. It doesn't bylaw. We just > cleared it out with the EasyAnt community. So let's clear it out with this > vote for the Ant PMC. > I also thought that EasyAnt should have a classical incubation period, doing > release and growing a community. But it has no sense since if EasyAnt is > accepted as a subproject of Ant, the Ant PMC will be responsible for EasyAnt > code and releases. > > So if we accept EasyAnt, the code will be imported, committers added. But > releases should be voted by us. I'm the only active EasyAnt committer which > is also an Ant PMC member. This means that other Ant PMC member should be > involved so that things can roll. We have been managing that with Ivy and > IvyDE, but this is something that should have in mind while voting. Also note > that it would somehow resolve itself it some EasyAnt developer become part of > the Ant PMC, some of them have already wrote some nice patches on Ant and Ivy > :) > > So, should we accept EasyAnt as a subproject ? > > > 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
[RESULT][VOTE] Accept EasyAnt as a subproject
I am closing the vote. I count 2 binding +1, 1 non binding +1 The proposition failed to be accepted. Further discussion will happen on easyant mailing lists. Nicolas Le 11 juil. 2012 à 10:48, Nicolas Lalevée a écrit : > EasyAnt is a project based on Ant and Ivy which is in incubation under our > "sponsoring". > > I kind of misunderstood the "sponsoring". I was thinking that it was implying > that EasyAnt will become part of the Ant project. It doesn't bylaw. We just > cleared it out with the EasyAnt community. So let's clear it out with this > vote for the Ant PMC. > I also thought that EasyAnt should have a classical incubation period, doing > release and growing a community. But it has no sense since if EasyAnt is > accepted as a subproject of Ant, the Ant PMC will be responsible for EasyAnt > code and releases. > > So if we accept EasyAnt, the code will be imported, committers added. But > releases should be voted by us. I'm the only active EasyAnt committer which > is also an Ant PMC member. This means that other Ant PMC member should be > involved so that things can roll. We have been managing that with Ivy and > IvyDE, but this is something that should have in mind while voting. Also note > that it would somehow resolve itself it some EasyAnt developer become part of > the Ant PMC, some of them have already wrote some nice patches on Ant and Ivy > :) > > So, should we accept EasyAnt as a subproject ? > > > 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
Re: [VOTE] Accept EasyAnt as a subproject
Hi I guess one of the problems we see here is that +1 doesn't just mean "why not?" but rather "yes!". I'm one of EasyAnt's mentors and have been watching it for quite some time now. TBH it has been veeery silent for a long time. Apart from Nicolas and Jean-Louis there is no active committer - and for some extended stretches there hasn't been any development at all. Sounds familiar, doesn't it? <http://www.ohloh.net/p/easyant/commits/summary> The Ant community isn't the most active one by itself, a new project might trigger more activity so I'm leaning towards a positive vote. I'm not sure the Ant PMC would be doing a good service to EasyAnt (you'd likely not get three PMC +1s given the feedback on this vote), but this is EasyAnt's decision. Stefan - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: [VOTE] Accept EasyAnt as a subproject
+1 On Jul 14, 2012 9:41 PM, "Bruce Atherton" wrote: > I think this is a great idea, particularly if we can get the committers of > EasyAnt interested in improving Ant and Ivy. > > +1. > > Would it be worthwhile to consider all the committers on EasyAnt as > committers on Ant if this is adopted? As I recall, that is what happened > with Ivy. > > On 12-07-11 01:48 AM, Nicolas Lalevée wrote: > >> EasyAnt is a project based on Ant and Ivy which is in incubation under >> our "sponsoring". >> >> I kind of misunderstood the "sponsoring". I was thinking that it was >> implying that EasyAnt will become part of the Ant project. It doesn't >> bylaw. We just cleared it out with the EasyAnt community. So let's clear it >> out with this vote for the Ant PMC. >> I also thought that EasyAnt should have a classical incubation period, >> doing release and growing a community. But it has no sense since if EasyAnt >> is accepted as a subproject of Ant, the Ant PMC will be responsible for >> EasyAnt code and releases. >> >> So if we accept EasyAnt, the code will be imported, committers added. But >> releases should be voted by us. I'm the only active EasyAnt committer which >> is also an Ant PMC member. This means that other Ant PMC member should be >> involved so that things can roll. We have been managing that with Ivy and >> IvyDE, but this is something that should have in mind while voting. Also >> note that it would somehow resolve itself it some EasyAnt developer become >> part of the Ant PMC, some of them have already wrote some nice patches on >> Ant and Ivy :) >> >> So, should we accept EasyAnt as a subproject ? >> >> >> Nicolas >> >> >> --**--**- >> To unsubscribe, >> e-mail:dev-unsubscribe@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] Accept EasyAnt as a subproject
On 12-07-19 02:50 AM, Jean-Louis Boudart wrote: > This topic doesn't look like popular :) > > Should we consider this silence as a "no go"? Well, I haven't seen any disagreement with the proposal. It looks more like just a general lack of participation in the dev group, partly from the fact that it is summer (in the northern hemisphere) and partly from the fact that we have been slowing down anyway. For example, this is just the 20th non-automated message that has been posted to this list in the month of July. If anything, the lack of conversation seems to indicate that we do need the fresh blood that EasyAnt would bring. Having said that, there do not seem to be the votes required to make this happen unless others are willing to jump in and vote. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
