ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roger Vaughn <rogervau...@yahoo.com>
Subject RE: if and unless attributes for all Tasks
Date Wed, 16 May 2001 13:20:30 GMT
--- Conor MacNeill <conor@cortexebusiness.com.au>
wrote:
> It is the same with if and unless. Those are the
> tools we have provided and
> a lot of problems can be solved that way, but
> sometimes it forces the build
> writer into unnatural contortions. The end result is
> that the build file is
> complex and the intent of the build file's author is
> lost. Compare Jose
> Alberto's target based example against the original
> in the patch. It works
> in the current Ant, but is it better?

At last, some clarity of thought!  I'm constantly
baffled by most of the core authors' insistence on
simplicity at all costs, especially in the face of
constant user requests for these features.  Face it
folks, builds aren't simple.  If the Ant features
aren't expressive enough, that complexity ends up
getting expressed in workarounds, and gross
bastardizations of the features Ant does have -
Conor's "unnatural contortions."  I've written a bunch
of these myself, and I've never been happy about it.

The complexity is inescapable.  I fully believe Ant's
charter should be to handle that complexity -
natively.  I have serious concerns when posters start
arguing for the inclusion of other solutions such as
BSF scripting, or template approaches like the XSLT
I've pushed a few times myself.  These are all
attempts to handle the complexity that Ant refuses to
deal with, and in the end make it harder for the build
scripter to understand the system as a whole.  Ok, so
Ant is simple and easy to learn.  But what good is
that if a real-life scripter also has to learn and add
on other languages in order to make it perform?

> I like this discussion since we should always be
> ready to question whether
> there is a better way of doing things. That is why
> I'd like to hear from Jon
> on his thoughts for a better way of doing the
> uptodate checks. uptodate is a
> direct result of the if/unless mechanisms we
> currently have. Is there a
> better way?

I think this was the original requestor's intent - his
better way was putting if/unless directly on tasks, so
you didn't need several meaningless targets to do a
few sequential steps.

If anyone has yet a better way, I'm all ears.  But
remember - programmers *understand* 'if'.  The more
esoteric you make the solution, the more audience you
lose.

> I see tasks as appropriate when you tend to do the
> same type of things in
> many places or in many builds. That is, I see them
> as a solution when you
> can apply them in multiple places. I'm wary of using
> tasks for ad-hoc
> conditional requirements in the build. Can you see a

+1 for that.  Add-in tasks aren't appropriate for
one-off solutions.  Unfortunately, in my case, I don't
get paid to write build scripts, and the more time I
spend on writing tasks, the more my clients want to
know where their code is.  Ant's extensibility is
admirable and unique, but writing tasks isn't cheap.


Peter brings up auto* as a way around make's
complexities.  Again, I think this is entirely
backwards.  Those tools exist because of make's
*simplicity*.  It doesn't have the expressiveness to
do iteration, templates, etc. and the make community
was reluctant to add those features, so add-on tools
were the only way to accomplish the things that real
people needed.  Is this a better solution?  Which is
more complicated?  make, or auto*+make?  How many
people understand each?  If you really study it, I
think you will find that auto*, Imake, and all of the
add-on solutions are *much* more complicated and less
understood (and thus less used) than make itself.

How does this apply to Ant?  In my opinion, I see the
Ant authors following the same path - simply creating
a Java version of make.  To handle complexity, we're
supposed to use BSF, or XSLT, or multiple build files
or some other "unnatural contortion".  The names have
changed but the game is the same.  Yes, I realize this
is a bit insulting, but my hope is that you guys will
seriously consider it.  Complexity is here to stay. 
You will serve your community best by giving them the
tools to handle that complexity - natively.


Roger Vaughn


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Mime
View raw message