Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-ID: <38A85C95.716752D8@apache.org>
Date: Mon, 14 Feb 2000 20:50:45 +0100
From: Stefano Mazzocchi <stefano@apache.org>
Organization: Apache Software Foundation
MIME-Version: 1.0
To: ant-dev@jakarta.apache.org
Subject: Re: discussion: build file format
References: <85256885.005628CB.00@d54mta04.raleigh.ibm.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

rubys@us.ibm.com 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,
> IMHO.

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

Hmmm....

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