Yes you're right both tools share the same objectives. There are a lot differences between Gradle and EasyAnt though.
Gradle *can use* ant + ivy whereas easyant is *based over* ant + ivy. On the technial part: Gradle provides a rich API to do a lot of things. You can do amazing stuff in a few lines that's really cool. But there are a few things i dislike in the approach. Gradle api offers an abstraction layer for ivy but doesn't support all ivy's features (such as "branch" or "status"). Dependencies are declared through a groovy DSL and ivy api is used under the hood. This means you can't use tools build over ivy (such as IvyDE, Hudson ivy's plugin, etc...). They offer an api to manipulate / create "Zip" , but this api doesn't support empty directories. Why are they reinventing the wheel instead of delegating to ant's ZipTask ? As a solution we can still use ant's ZipTask (the ant one) but the syntax is mainly different with the one provided by Gradle api. This can create confusion. Gradle understand Ant's world, so it's easy to reuse ant's script. It will then access to everything defined in your antscript (targets, datatypes,etc...). At the opposite Ant will never be able to access to gradle's world. You can invoke a gradle script, but nothing more. You can't import a gradle script in your own build.xml and access to properties, targets or any datatype. EasyAnt is based on Ant + Ivy so you can use all the power of both tools without reiventing the wheel and still keep compliant with additionnal tool (like IvyDE). On functional part : Playing with standard project takes one line of Gradle's script ! Impressive ! This is the strengh of Gradle based on conventions. It is also possible, if needed to extends / adapt / override (and much more) using groovy. The problem here (at least for me) is that there is no distinction between project description (organisation, module name, revision, dependencies, plugin used, a few properties) and customizations. So maintaining gradle scripts can be a hell! Imagine dependencies lost in the middle of tasks... As there is not yet good IDE integration you need to know well groovy + gradle api's + ivy + ant (and sometimes maven). Now about groovy DSL : I must admit that it's easier to make if statement, loops in Groovy. But the real question is who needs this ? the end user ? the script writter? To be honest i believe most of the people doesn't understand all this stuff building, dependency management etc... Instead of shooting oneself in the foot by giving them all the powerness of a language like groovy, i would prefer giving them something easy but structuring. In EasyAnt we try to reuse one of the main principes of Maven : having a declarative approach (in opposition to scripting approach). This means, as a enduser point of view, that you need to describe your project constraint (organisation name, module name, version, does my project have dependencies ? is it a jar/war/ear? Should i want to use coverage ? Should i want to generate javodoc / Apache RAT report ? etc...). This is done in a "module.ivy" file, our module descriptor (equivalent to pom.xml). This module descriptor is a true ivy file understood by ivy. It contains additionnal attributes for easyant to defines a limited options such as properties or plugins. IMHO, XML is good here as it enforces users to use a tool in a structured way. Then if existing plugins don't feed your needs, you can write your own plugin *or* have an additional module.ant file (a pure ant script similar to a build.xml). This allows advanced users to adapt/extends plugin behavior or to define your own. Now as a plugin writter we got your point, writting if statements, loops is not sexy in XML. That's why we plans to support alternatives language fully compatible with ant. Alternatives project helpers like JavaFront or GroovyFront provide all we need for this. That's why we were really interested in mixing multiple project helpers (development made by Nicolas). About the spirit: EasyAnt is open source ! Oki but this doesn't limit to open our code on a public repo with a few license headers. We choose to base our solution on ant + ivy, and instead of doing things on our side we would prefer to take more time and check if some features can be reinjected in Ant or Ivy like we've done with : * include mechanism * extensionPoint (ex Phase) * module inheritance in ivy And there more we would like to reinject * bindtarget (kind of syntax sugar to change how a target is bind to an extensionPoint without creating intermediary targets) Already in discussion :p * JarResolver (for ivy) allowing to deal with repository shipped in a "jar" file I'm pretty sure the more we will work on easyant the more we will have ideas to share. Regards, 2010/11/12 Antoine Levy-Lambert <anto...@gmx.de> > Hi, > > I have just taken a look at the documentation of easyant. Do I understand > well that this project is similar in scope to gradle ? The scope being to > deliver a build system using ant and ivy with a set of conventions allowing > most likely to setup builds very fast if one is happy with the default > conventions. > > I have never used easyant nor gradle but from what I can read on both web > sites I would prefer a priori gradle. The fact that gradle scripts are > written in groovy and so have a natural support for all usual language > constructs such as if statements and loops is useful, especially when one > uses ant to do deployments or other automation tasks. > > That being said I am not going to veto easyant joining the ASF and becoming > part of the ant family of projects. I see that we will get that way more > committers for ant and the ant family of projects will probably benefit from > becoming bigger. > > Regards, > > Antoine > > > On 11/12/2010 5:45 AM, Nicolas Lalevée wrote: > >> Needless to say that I am highly supportive of this proposal, and I am >> willing to help in the process. >> >> Following the incubator's doc [1], I would say that a good fit for a >> "Sponsor" would be Apache Ant. We shall vote if there is no prior objection. >> >> Then about Mentors and a Champion, I am not myself qualified, even if I am >> motivated. >> So we are seeking here for a Champion and some Mentors :) >> >> Nicolas >> >> [1] >> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html >> >> Le 11 nov. 2010 à 19:19, Jean-Louis Boudart a écrit : >> >> Hi, >>> >>> EasyAnt team would like to get more visibility and build a bigger >>> community >>> based on real "open source spirit". As we're already based on many Apache >>> project (Ant + Ivy), it seems natural for us that Apache Software >>> Foundation >>> could be a good host for this. >>> >>> Before starting the proposal process ( >>> http://incubator.apache.org/guides/proposal.html) i would like to know >>> if >>> there is anybody here that can help us in this process. >>> >>> Project Context : >>> ----------------- >>> Easyant is a build system based on Apache Ant and Apache Ivy. >>> 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 easy as writing simple >>> Ant scripts as Easyant plugins. >>> >>> 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 with Easyant. >>> >>> Legal part : >>> ------------ >>> The code has been developed under the ASL2 license and by six >>> developpers: >>> Xavier Hanin, Jérôme Benois, Jason Trump, Siddhartha Purkayastha, Nicolas >>> Lalevée and me. I've already discussed about this with our team, they are >>> joining me in this request and are willing to sign any software grant >>> paper >>> necessary. >>> >>> >>> -- >>> Jean Louis Boudart >>> Independent consultant >>> Project Lead http://www.easyant.org >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org >> For additional commands, e-mail: dev-h...@ant.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > For additional commands, e-mail: dev-h...@ant.apache.org > > -- Jean Louis Boudart Independent consultant Project Lead http://www.easyant.org
