RE: executing task for each file in file set

[Peter Vogel <pv...@arsin.com>]

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
> 

Re: executing task for each file in file set

[Stefan Bodewig <bo...@apache.org>]

Peter Vogel <pv...@arsin.com> wrote:

> Personally, I'd like to see the ant designers stop "babysitting" the
> development community to prevent what they view as "bad practices".

In my case, it's less about babysitting the users than preventing that
"bad practices" applied by users will be used as an argument against
Ant.  Maybe I'm overreacting from time to time, don't know.

> Please stop assuming you've encountered every SCM/build management
> problem on the planet.

I've never done that, I'm always asking for examples of the bigger
"build management problem"s.  I'm a developer who happens to also be
the build manager in our shop, but I really wouldn't conside myself an
expert in this area.

> and let the people who manage source for a living figure out the
> right way to use it for their situation.

I'm less concerned about the "people who manage source for a living",
really.

You've said more than once, that the common "recursive makefile"
pattern found almost everywhere in the make world was bad, even when
applied to make.  This means, that there are other, better ways to
manage complicated builds in make, but for some reason, most users
choose the inferior solution.

Say we'd add foreach to the core - and I'm more and more leaning
towards it (making myself a heretic, I guess 8-) - and we already have
those many cases where we successfully anticipated the need for
iterations like javac, execon, apply and in the future anton, javaon.
What can we do to make user chose the "right" thing?

> Were it not for the javac task in ant, I'd hazard a guess that ant
> would not enjoy the popularity that it has.

Probably - at least this has been the reason to start with and is the
most important argument in the make vs. Ant discussion.

In the meantime Ant has gathered some other quite popular tasks that
show what could be done with tasks - ejbjar and junit are quite
prominent examples.

Stefan