> > > 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.
I guess my point is that "bad practices" will happen, no matter what you do to prevent them. In Ant's case, it's way to possible to commit a multitude of sins in a series of optional tasks that unnecessarily bloat the "vocabulary" of build description when it would be better to have a more limited set of useful words in the core (i.e. foreach, if, etc.) I challenge you to describe what a number of core and/or official optional tasks do without using the words for, each and if. It's a natural part of the build process. > > > 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. You, Stefan, are actually one of the bastions of reasonableness on this list... > > > 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. It's a side-effect of a self-replicating pattern. Early make tools lacked the power necessary to avoid recursion, so that's what people did. When the more powerful tools (the include directive in many modern make tools) became available and made the recursive pattern obsolete, few people noticed... The non-recursive makefile pattern also takes a few minutes to wrap your head around if you are used to the recursive pattern. > > 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? Documentation is one, but even more importantly, lead by example! Let me step away from Ant for a moment and talk about Perl. There are a lot of people out there who unfairly malign perl as a "write-once" language and it is certainly possible to write code that way. As a counter example, I frequently offer my own perl programs as a "model" of readability and maintainability, I know they meet these criteria because I have some scripts that have been used and re-used and maintained by many people over a number of years. When people see perl the way it *should be* written, their opinion begins to turn in favor of the language. Ant is the same way -- no matter what you do, there will always be people like Inco P. Tent who can make Ant look bad without much effort on their part. That doesn't mean that ant should do something that is obviously out of ant's scope, or that fundamentally alters an ant design decision, but it does mean you need to suppress the knee-jerk reaction when you see a proposal that uses a word found commonly in scripting languages and ask yourself if that proposal furthers the cause of the ant file being a build descriptor and the ant program being the process which performs the work described... > > > 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. Haven't had a need for them yet. I find it interesting that the examples most often cited for best meeting the goals of ant are not a part of the "core" and are very special-purpose (one is exclusively for use with WebLogic based projects, the other is based on a testing framework). That said, they both look like good examples of appropriate use of ant's extensibility, there are others in the optional library that look like good examples of someone prefering to write a java task than to use the "<exec>" tag. For example, "cccheckin" which doesn't even traverse a directory tree and essentially equates to the <exec> task... -Peter
