ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse Tilly <>
Subject RE: if and unless attributes for all Tasks
Date Wed, 16 May 2001 20:13:45 GMT

I cannot draw from the years of experience you have had.  While I am a part
time configuration manager, it is not my title nor my "day job" and I have
only been involved with these concepts for about 4 years.  What your
experience could bring to Ant is valuable so I have a few questions, if you
don't mind:							

Given Ant's current state, how would you address conditional processing?

If given the choice between continuing the use of XML or moving to another
description language, which would you choose for Ant?

Given this scenario:

Company/group starts work on a somewhat interdependent set of projects that
all culminate into a final web application.  This application is
distributable (meaning it can be hosted from multiple sites globally) and
consists of Java (RMI, JNI, EJB, servlets, JSP), HTML/PHP/ASP, graphics, and
a database schema.

What tool would you begin using to build, deploy and distribute this
application?  Would Ant factor in at all?  Why or why not?

For everyone else, Peter obviously brings up the main point in any project:
what problem are we solving.  I do not like to be considered closed or
elitist when discussing design and I'm my colleagues would not like to be
described this way, either.  However, the gauntlet has been thrown.  When
someone of Peter's experience level describes the tool as incapable of use
beyond small projects I, like everyone else, would like to know what
particular points are lacking.  Defining the problem and "contract" (a term
Roger and Peter have both used quite accurately) is key to Ant2.  Is it key
to Ant now?  I don't know.

To help you understand why I question these things, Peter, let me explain my
dilemma.  The more Ant begins to aggregate ad-hoc solutions into its core,
the less manageable it becomes.  I'm sure you're aware of this in projects
for which you've managed the configuration.  However, another dynamic takes
place.  The more "useable" it becomes, the less likely the perceived better
solution will be adopted.  We witness this everyday in technology.  Everyone
wants to use what works and what works now.

I hoped (and was rewarded) that my statement would begin a discussion from
the primary developers of Ant and provide a forum for drawing out my main
concern: is Ant doomed?  Hopefully, Peter, your answers to my question will
help me (and others who are interested) find out where Ant stands in the
real-world.  Thanks for your time in advance.


> -----Original Message-----
> From: Peter Vogel []
> Sent: Wednesday, May 16, 2001 1:49 PM
> To: ''
> Subject: RE: if and unless attributes for all Tasks
> Heh!  Well said Roger!  The "we don't think its a good
> idea, so Ant won't include it" is one of the reasons I
> am hesitant to recommend Ant, despite the great leaps forward
> that have happened since I started following ant at 1.1.
> I've been architecting builds for over a decade now, using
> a variety of tools (Make, Cons, Perl wrapped around Make, ant, 
> etc.) and there are some fundamental capabilities that are
> *necessary* to ensuring reproducible builds (which is the 
> whole point of CM) which Ant simply lacks, environment 
> encapsulation being one of them, a cleaner way of
> doing conditionals being another.
> I'm a big proponent for a framework that is *simple* when
> it can to be simple, and which makes complexity readable
> when complexity is needed.  The whole concept of "write a 
> task to do that" while cool for certain things, is fundamentally
> broken for fundamental things like conditionals, etc.  
> Conditionals in build files are a fact of life in today's
> cross-platform software systems, and even in some that aren't
> cross platform, but which need to be configurable at
> build time.
> That said, Ant is still a pretty cool tool, and I use it when
> its appropriate, but I do get pretty annoyed by the "we're
> smarter than you" attitude from many of the ant development
> community that seems to consider anything that smacks of 
> "complexity" as evil.  Go design an ant-based build of a 
> system consisting of 2M lines of code that produces 4 different
> products with 90% of the components being shared across those
> products and then tell me what features should or should not
> be in the product.
> -Peter
> --
> Peter A. Vogel
> Manager+consultant, Configuration Management
> Arsin Corporation, Professional Services
> > -----Original Message-----
> > From: Roger Vaughn []
> > Sent: Wednesday, May 16, 2001 7:42 AM
> > To:
> > Subject: RE: if and unless attributes for all Tasks
> > 
> > 
> > --- Jose Alberto Fernandez <>
> > wrote:
> > > How understandable build files will be depend on our
> > > choices. If I write
> > > targets where every <task> has a different if/unless
> > > condition, what does
> > > that tell me about the readability of the build
> > > file. It looks like
> > > spaggetti code to me. I think the granularity is too
> > > low. By having
> > > if/unless at <target> level, you still can write
> > > spaggetti code, but it will
> > > make you think: "Do I really need to do it this
> > > way?" And that is what makes
> > > code understandable and maintainable, you have to
> > > stop and think.
> > 
> > You can obsfucate anything if you try.  For instance,
> > it is entirely possible to specify one task per
> > target, and link them all up with dependencies.  We
> > don't do that because it's harder to understand.  But
> > it's certainly a simpler, more declarative model than
> > multiple sequential tasks per target.
> > 
> > I'm going to come out on the side of more features,
> > more power, and more flexibility every single time. 
> > There is always some rube who is going to program
> > himself into a real mess, but I don't think that's
> > sufficient excuse to deny others of us flexible tools.
> >  FWIW, I feel exactly the same way about Java vs. C++,
> > even though I do the majority of my work in Java these
> > days.
> > 
> > BTW, I'm still hoping for mutable properties (or
> > perhaps a separate set of variables.)  ;)  Used
> > *judiciously*, they can, in certain situations,
> > simplify scripts quite a bit.  Now, if someone goes
> > wild and creates what you describe above, well then,
> > that's his fault, not mine.  This isn't a support
> > organization, so I don't think protecting users from
> > themselves should be the team's first concern.
> > 
> > There's a certain arrogance here that's frequently
> > annoying.  The refrain "we don't think you should do
> > that, so Ant won't include it" is heard pretty
> > frequently.  I understand reluctance to implement
> > difficult or basis-shattering features (like
> > templates), but for simple things, I just don't get
> > it.  Come on guys, be open to new ideas and different
> > ways of doing things.  If anyone finds this insulting,
> > well, I'm sorry, but that's what I see.
> > 
> > roger
> > 
> > 
> > __________________________________________________
> > Do You Yahoo!?
> > Yahoo! Auctions - buy the things you want at great prices
> >
> > 

View raw message