ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <>
Subject Re: [EasyAnt] first proof of concept
Date Sat, 23 Feb 2008 12:05:16 GMT
On Sat, Feb 23, 2008 at 11:55 AM, Nicolas Lalevée <> wrote:

> 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.

Indeed, it's kind of reproduced here, except that I've used fixed versions
for each build module, so with Ivy cache the build system is cached at first
call and don't use any network connection on later calls. You need a network
connection only if you use a new build module, or specify to use a latest
version of a build module (which would mimic maven auto update mechanism,
but that I'd decourage).

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.
> that.

Indeed, clearly separing steps is a good idea. With Ivy cache as I said we
already have some support of this as is (and with recent support for TTL for
dynamic revision resolution, we could even support some kind of on demand
update mechanism, by using an infinite TTL and the refresh mechanism).

But we could make it even more separated, having an explicit step to
initialize the build system, putting everything in the modules directory as
it's done in the POC. Then you use a local only build system, which is much
easier to understand.

BTW, we are only talking about the build system itself here. The process of
resolving module dependencies is another aspect, with different needs in
change management.

> 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 ?

Well, I see it as an equivalent of a simple and basic pom.xml. One thing I
dislike with pom.xml is that they mix project metadata (such as id,
dependencies, project type, ...) with some build specific information (such
as configuration of build plugins). Then when you publish a maven module you
end up with all this information in your repository, while I don't think
they fit very well in a module repository. So what I envision is a slightly
enhanced ivy.xml, with very basic information used for the build itself:
module type (ie the main build module to import), and some properties to
customize the build. If you need more, you write a module.ant file, in which
you have the full power and flexibility of Ant.

> 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 ?

As I explained earlier, I personnaly prefer to isolate module metadata from
build logic. module.ivy is for module metadata, module.ant is for custom
build logic if necessary. But in most cases I'd encourage creating a custom
build module, and importing this module, rather than creating a module.antfile.

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

I thought it was more consistent with the module.ivy naming convention, and
the usage is slightly different from a build.xml: in all cases easyant
actually use its own ant file (easyant.ant) to load the module specific
files (including module.ant). But I agree this is very similar to a
build.xml, so maybe we should drop the module.ant concept in favor of
standard build.xml when the user want a module specific build.


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

Xavier Hanin - Independent Java Consultant

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message