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 17:04:17 GMT
--- Peter Donald <> wrote:
> At 07:48 AM 6/6/01 -0700, Roger Vaughn wrote:
> >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" 
> projectref as described by Jose *is* wrong ;)
> projectref as originally
> defined is right (and needed).

I could again argue about the use of "wrong", but I'll
leave it.  I hear your central argument, that Jose's
interpretation affects the core.  I'm not sure I
really agree, but I'm not in a position to know for
sure, not having done the background work - and not
being on the line for delivering it.  Assuming it is
as you say, I have to agree in principal - the change
to the core should cause you to approach it more
cautiously.  I still don't say it's "wrong" - core
changes in the past and I'm sure in the future
have/will make Ant more usable.

> theres plenty of examples - I agree 100% with need.
> I was ... *educated*
> ... about it's usefulness recently. It is how the
> functionality is provided
> that is the tickler.

I have no problem with that.

> in my eyes templates will be 90% for people like you
> and not of real use to
> novices or small/simple projects.

Accepted.  Unfortunately, novices are often given this
task.  :-)  Not much we can do about that, though. 
And I can't *count* the number of companies/projects I
have seen with NO formal build process.

Because of that, I'm a bit torn.  I'm half of a mind
to claim that making a build tool more accessible to
novices would be a good thing.  Perhaps more projects
would adopt a real build cycle then.  But then I
cynically think that most people wouldn't change their
ways no matter what.

And "simple build tool" might very well be an

> >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 am not sure that is a bad thing ;) 

I tend to think it is, as it reduces the ability to
reuse/share work between projects.  This may be less
of an issue than I think, as the same people who would
share work will likely collaborate or take their
templates with them anyway.

> >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.
> could you clarify?

Sure.  As I mentioned previously, external templating
gives you at least three languages to learn and work
with - the "generator" language (which the template is
expressed in), the template language (which the
template expresses), and the Ant language itself.  A
build engineer will be involved in all three -
ideally, a build writer will only need to know the
template language.  Necessarily, there is more to
learn and understand - and use properly.  There are
more chances to make mistakes - and not just based on
feature count, but on syntax count.  Ant has one
syntax.  This little scenario has at least two (Ant
and generator).

Assuming you use XSLT as your generator language, you
have a whole can of worms just in that one piece.  It
seems many people have a hard time learning how to use
XSLT effectively, and some just refuse to touch it. 
It is a difficult language to master.  Because of
this, I would expect people to make more mistakes -
and more severe ones - in it than they would in Ant
itself, since Ant has been designed from the start to
be easily accessible.

> I don't think generators/guis should be fezzing with
> template files. The
> templates are written by experts who presumably know
> what they are doing
> and can work better in a XML editor (or text
> editor).

Oh, absolutely.  Generators should never work with the
template language.  My point is just that by saying
"you must use templates to achieve functionality X",
we cut off a whole class of problems that require
functionality X from the people who would use the GUI

Also, I can guarantee that if and when templates are
supported, *some* generator *somewhere* will generate
everything into its own proprietary template
implementation.  I *don't* think that is a good thing.
 But can or should we prevent it?  Probably not.

> possibly but that makes everyone pay for the power
> regardless of whether or
> not they use it. Personally I would like to have if
> tasks for use in
> templating. Providing this feature would inevitably
> lead to misuse by users
> who shouldn't be using it. So while it would be nice
> for me to use, it
> would cause pain to less experienced users, thus I
> would never support it's
> inclusion in core.

I'm going to fall on the other side of this fence
every single time.  I have the same argument with many
of the core Java language decisions.  I cannot agree
with a tool builder trying to protect people from
themselves.  To me, "someone will misuse it" is not a
valid argument.  *No matter what* you provide, someone
will misuse it.  I will always argue for providing
functionality for those who can use it, and letting
those who would create their own messes deal with

Every tool, every language has a learning curve.  If
you haven't prepared adequately to use it, then you
should not be using it - yet.  That's not the fault of
the tool.

Now, this doesn't mean I espouse chaos.  Yes, Ant
should follow good design principles, and yes, Ant
should allow for clean build implementations - without
extraordinary effort on part of the build writers. 
There are a handful of tools (not necessarily build
tools, and not Perl ;-)) that *force* you to follow
flawed principles, and this, obviously, none of us
want Ant to be.

Ant should allow people to write elegant, correct
scripts, plain and simple.  IMHO, if this means a few
people can (not must) abuse that functionality, so be

And yes, I like Perl.  Sure, you can write bad code in
it, but it doesn't force you to.

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

View raw message