ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <pvo...@arsin.com>
Subject RE: executing task for each file in file set
Date Sun, 10 Jun 2001 06:39:21 GMT
Personally, I'd like to see the ant designers stop "babysitting"
the development community to prevent what they view as "bad practices".

Let each shop define its own standards of "behavior" in ant, just
as they do (or choose not to do, for whatever reasons) for Java
coding standards, C/C++, etc. 

Please stop assuming you've encountered every SCM/build management
problem on the planet.  Build a *coherent*, *consistent* build
management system and let the people who manage source for a living
figure out the right way to use it for their situation.

Were it not for the javac task in ant, I'd hazard a guess that
ant would not enjoy the popularity that it has.  Please recognize
that the inconsistencies that exist today are, in fact, *exactly*
the sorts of things that you purport to despise in your blind insistence
on "simplicity" and "not being like make".  

Forgive the tone, please, it's late, but it is *so* frustrating to see
a tool with *real* potential spilling that potential down the drain
with petty bickering among the committers and constant derision of 
features that are clearly useful in real-world situations.

-Peter


> -----Original Message-----
> From: Daniel Barclay [mailto:Daniel.Barclay@digitalfocus.com]
> Sent: Wednesday, May 23, 2001 7:18 AM
> To: ant-dev@jakarta.apache.org
> Subject: Re: executing task for each file in file set
> 
> 
> Peter Donald wrote:
> > 
> > At 04:25 PM 5/22/01 -0400, Daniel Barclay wrote:
> > >I was asking more about how solid a set of standard 
> features Ant tries
> > >to provide.
> > >
> > >(Obviously, Ant provides a lot, but with its inconsistencies and
> > >limitations and the frequent suggestions to just write 
> custom tasks for
> > >(arguably) generally-useful features made me wonder what 
> the philosophy
> > >of the designers was and whether arguing for cleaning up 
> various features
> > >would be likely enough to be successful to be worth the effort.)
> > 
> > I say go for it ;)
> > 
> ....
> > 
> > We will probably have a Task API (similar to Servlet API) and a task
> > framework (similar to turbine/struts/other). The task 
> framework is where
> > all the "work" is done like defining filesets, filtersets 
> etc. As far as I
> > am concerned we should clean up all tasks to use same 
> conventions and reuse
> > framework where possible.
> 
> I was more thinking about things from the build-file-writer's point of
> view, things like:
> - only certain things can appear at the top level (outside a target)
>   (e.g., <property...> but not <available...>)
> - file sets only take patterns; they don't take direct file names
>   (Windows absolute file pathnames don't work, relative file pathnames
>   with ".." segments don't seem to work, etc.)
> 
> For ideas that have been rejected, are they permanently rejected?
> 
> Do the Ant designers seem to recognize the value of making 
> things regular
> and consistent for better "composability" of features even if 
> a specific 
> need isn't imagined yet?
> 
> I'm thinking about constructs that can appear at the top level.
> 
> I know some (maybe you?) reject the idea of allowing 
> arbitrary tasks at 
> the top level, feeling that that would allow someone to write 
> an Ant build 
> file with everything done at the top level (with no targets), 
> and since 
> that's not considered to be a good idea, Ant should not allow that.
> 
> However, just because a feature lets you do something "bad" 
> doesn't mean 
> the feature shouldn't exist; maybe it has legitimate uses and 
> should be
> available, and just shouldn't be misused.  
> 
> (E.g., most people agree that one shouldn't normally write 
> thousand-line 
> methods or functions.  However, no mainstream programming 
> language prevents
> doing that, because no particular arbitrary line limit would satisfy 
> everyone.  Additionally, uses not originally envisioned 
> (e.g., generated
> code) might be perfectly valid but made impossible or much 
> more difficult
> by a line limit.)
> 
> (Also, note that Ant currently allows one to put every task 
> in one big 
> target anyway.)
> 
> I know there's concern about leading people into bad 
> practices (more than 
> just allowing them) but I don't think that's a problem for 
> this particular
> issue.  
> 
> Anyway, I'm zoning out a bit, so I don't really have a coherent 
> conclusion...
> 
> 
> 
> Daniel
> -- 
> Daniel Barclay
> Digital Focus
> Daniel.Barclay@digitalfocus.com
> 

Mime
View raw message