ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <hol...@yahoo.com>
Subject RE: if and unless attributes for all Tasks
Date Wed, 16 May 2001 20:21:40 GMT
Guess I should probably chime in on the pro-Roger side as well. I'm
wondering if the difference in perspective could be linked to those of us
who are primarily build-engineer types. When I look for a build tool, I
look for one that's going to be best for the situation at hand -- and,
like Roger, I picked up on Ant primarily for its ability to handle java
compiles (and other Java-oriented things, like jar'ing, etc.). I also look
for a tool that's straightforward to use at the level that the developers
need to use it -- ie., being able to just say '<buildtool>' for compiles,
and easy modifying of the build-files for simple changes like
adding/deleting source-files. Anything more complicated, they can either
ask me to implement, or they can get into the tool deeper and work it out
themselves -- but my experience has been that 99.9% of them don't want to
get into it at that level. But I have to, so I also want a tool that's
able to handle the complexities that are bound to pop up when dealing with
all the things needed to do the full product builds/tests/installers/etc.,
and without having to do any  (or at least not too many) "ugly
contortions" (as Conor put it -- or "pretzled crud", as I put it, back
when I was asking for a test-for-equality :)

I have a Swiss-Army knife. I don't think I've ever used more than two or
three of the "blades" that are available with it (I can't imagine why
anyone would ever need that little saw :) But having those options doesn't
make it a Rube Goldberg device -- it's still a compact, well-designed,
simple-to-use tool. And I think that's all people have been asking for --
to not have things dismissed out-of-hand simply because someone else
doesn't have a need (at this point) to use them, but to look at whether
what's being asked for can be added without over-complicating the tool
itself. The test-for-equality mod that I have for the if/unless in my Ant
doesn't interfere at all with using the if/unless as you "normally" would,
it's maybe 5 or 6 lines of code, I only use it in one place in my whole
build -- but having it available sure makes things easier for that place
in the build where a test-for-equality was what I needed.

Like the saw-blade, I don't know that I'd ever need an if/unless at the
task level (can't think of a situation at the moment where I'd need it),
but I think the criteria for deciding whether to make it available should
be based on whether adding that capability will make Ant more useful to
people who do see a need for it and whether it can be done without
interfering either with the ease-of-use of the tool for those who don't or
with the maintainability of the (source-code for the) tool itself.

Diane

--- Peter  Vogel <pvogel@arsin.com> wrote:
> 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
> http://www.arsin.com  
> 
> 
> 
> > -----Original Message-----
> > From: Roger Vaughn [mailto:rogervaughn@yahoo.com]
> > Sent: Wednesday, May 16, 2001 7:42 AM
> > To: ant-dev@jakarta.apache.org
> > Subject: RE: if and unless attributes for all Tasks
> > 
> > 
> > --- Jose Alberto Fernandez <j_a_fernandez@yahoo.com>
> > 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
> > http://auctions.yahoo.com/
> > 


=====
(holtdl@yahoo.com)



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

Mime
View raw message