ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: discussion: build file format
Date Mon, 14 Feb 2000 19:50:45 GMT wrote:
> Pier (scared) wrote:
> > Stefano Mazzocchi wrote:
> > >
> > > Anyway, do you realize how incredibly more complex Ant would become if
> > > we make this step?
> >
> > I love ant because it's simple... The only thing I wouldn't see to
> > happen is to get, at the end, an ANT that is more complicated than a
> > Makefile...
> Perhaps I misinterpreted Stefano's remarks.
> What I see as motivating this discussion is a desire to make the Ant syntax
> simpler in cases where it is too cumbersome today, and leaving the
> remainder as is.  Achieving this may come at the cost of making the
> internal implementation more complex.  This would be the right tradeoff,

I agree. The use of project -> target -> task reflects a fault in the
overall design: the use of attributes-only DTDs has intrisic problems.

> If however, Stefano meant that this would make the syntax more difficult to
> learn and use, then I agree that we should stop right here.

No, no, I was talking about "internal complexity" only. I think that
what Sam proposed is a very nice feature we need to make it "easier" to
use Ant even in more complex systems.

Pier, remember the old-time discussion about flat configurations vs.
tree-like configurations? This is what it is. In fact, talking about
design patterns (which is, sorry, the way my brain works...), a
flat-file is a particular tree with a hidden root.

For Ant as it stands today, the use of XML is just functional but
nothing really important from an application perspective: you could have
a bunch of flat files that do the same job.

But if you start adding complexity, like token filtering capabilities,
complex matching for inclusion/exclusion, etc..etc... the use of the
"task + attributes" pattern is limiting and forces you to create strange
tasks that do nothing by themselves but trigger functionalities in the
project ("property", "filter", "available")

I'll be happy to see a "cleaner" architecture reflected by a more
structured build file.

On the other hand, I'm seriously concerned about the complexity required
inside the software to handle such a structured data buinding.... but
Sam suggestion cleared it a little...


Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message