ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: [EasyAnt] first proof of concept
Date Sat, 23 Feb 2008 10:55:47 GMT

Le 1 févr. 08 à 20:31, Xavier Hanin a écrit :

> Hi,
> Some time ago I've launched a discussion about a new Ant+Ivy based  
> build
> system, that I called EasyAnt. Based on the discussion we've had so  
> far,
> I've developed a small proof of concept, which is available here:
> If you have some time, please have a look, there's a README file at  
> the root
> of the main directory in the zip, explaining how to try it, and how it
> works.
> I'd appreciate to get some feedback on the concepts developed, and
> especially those requiring changes in Ant: mainly use and extends  
> mode for
> Import and the phase concept (explained in the README and more  
> extensively
> in the todo.txt).
> Xavier
> PS: don't pay too much attention to the code itself, it's rather  
> ugly and
> undocumented, but it's just a POC :-)

I like the idea but as an end user I had a very bad user experience is  
using maven because it resolve the build before using it. And it seems  
to be reproduced here. I would prefer a tool like the linux  
distributions are using. There is a special tool to manage the  
download of the latest component, resolving dependencies so ensuring  
that the downloaded tools are consistent.
For instance we could imagine having some targets easyant:init and  
esayant:update which should be similar to an "apt-get install" and an  
"apt-get dist-upgrade". So after successfully calling these targets  
the end user will be able to use its build system offline without  
worring of the consistent state of its build system.
Then there are the "apt-get update" and the "apt-cache search"  
features which would be very cool, but I wonder how Ivy could support  

Then about the implementation, here are some few questions:

I don't understand exactly what is the module.ivy in the exemple. Is  
it a strict equivalent to the pom.xml, so it will replace a build.xml  
+ ivy.xml ?

Then quoting the README:
"The idea is to have a very limited options of customizing the build  
in the Ivy file: settings
properties, and telling which main build module shold be imported. If  
you need more, you have to use
a module.ant file."

Why not just having a module.ant ?
And then why naming it module.ant, couldn't it be a classic  
build.xml ? What will be the difference for the end user?


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message