ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Vaughn <>
Subject Re: Configure->Template->Build
Date Wed, 06 Jun 2001 14:48:50 GMT
--- Stefan Bodewig <> wrote:
> I agree - and I think Peter does as well.  The
> thread started out with
> Peter asking which combination of tools he should
> use to create his
> prototype - so we can evaluate the impact - and
> somewhere down the
> thread I said I wouldn't care too much ...

Ok, I'll accept that.  It just seems that the disc.
has turned to "is it right or not".  Peter *seems* to
argue that <projectref> is "wrong" or "bad" - and my
point of view here is, if it doesn't change the core,
it isn't bad.  If you don't like it, don't use it.  I
have NO problem with that.

> Most of the problems people have with Ant - at least
> those people
> asking for loops and such - stem from the fact that
> they are trying to
> make Ant fit the paradigm they've been using in
> their respective build
> systems before they switched to Ant IMHO.

Not necessarily.  That's one issue I have with some of
these discussions.  You can't automatically make that
assumption.  I will agree that in many cases, you are
correct, but there are still cases such as myself who
*have* shifted gears but still want new features (such
as iteration).  It happens that the Ant syntax
encourages the use of iteration, etc. in certain
circumstances since the Ant targets do not operate
directly on files.  There are cases and files which
are not currently covered by tasks (eg. non-Java
files) that could be handled more elegantly with some
of these features we ask for.  (And no, I don't have
an example ready at hand - I'm just on my soapbox.)

> My major concern here is: Give them static templates
> and they don't
> even bother looking up another way of doing what
> they need with Ant.
> They'll talk about the complexity of XSLT and say
> Ant would be
> difficult to learn and all that.

I have to agree with your point, but on the flip-side,
many of those same people will never make the effort
to learn XSLT or any other solution, either.  I would
bet that such things would probably never even occur
to them.  In response, they will end up writing
horrible Ant files.  Is it really the team's charter
to prevent that from happening, or is it instead to
ensure that 90% of build file writers *can* write
clean files?

It seems a central issue of many of these discussions
is the composition of the target market for Ant -
novices or experts.  My target audience is of course,
myself, expert.  But I certainly can't dictate that to
the team!  ;-)  Perhaps clarifying who Ant is intended
for would help keep some of these disc. from getting
antagonistic.  (There it is again - ant-agonistic.)

> If we have some static templating mechanism I
> strongly wish that we
> brand it as "this is not Ant".

Agreed.  I have used XSLT "templating" myself, and I'm
very happy with the way it lets me assemble simple new
pseudo-tasks in much less time than it takes to write
the Java.  However, as Jose pointed out, there is a
huge danger of Ant fragmenting into a different local
"dialect" for every project out there.  I also think
external templating (or configuration) carries a much
greater potential for abuse from careless programmers
(which Peter is concerned about) than do most
potential new Ant features.

If this fragmentation occurs, then no one is using
"Ant", but rather their local build language.  No, you
can't call that Ant.  Also, Jose's points about the
effect on Ant generators and editors is an excellent
one that I had not previously considered.  (Probably
because I don't like generators much myself.)

Even though I have used the XSLT approach and do like
it, I am expert at this stuff.  I cannot see
recommending it for widespread use, as it is
remarkable similar to the Imake debacle.  Imake is a
powerful tool, but saw very little use because of its
complexity, not the least of which was the use of
three separate languages (the Imake "language" - cpp,
the make language - itself incorporating several, and
the local dialect Imake was to process).

IMHO, any approach that treats Ant the same way will
most likely meet the same reception.  Any solution
that requires additional languages to complete the
build will be necessarily more complicated to learn
and maintain.  For that reason alone, I personally
would rather see the Ant core language itself become
more expressive.

Ok, enough soapbox for today.  ;-)

> > There is obviously demand (and therefore need) for
> this type of
> > functionality, so who are we to say it is "wrong"?
> Which functionality exactly?

I was specifically referring to the templating
functionality - in whatever implementation - but this
could equally well apply to other controversial

Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!

View raw message