--- James Bucanek <[EMAIL PROTECTED]> wrote:<project name="workhorse" default="main" start="init" finish="cleanup" success="incrementsaleries" failure="firesomeone"/>
I think the problem I'd have with project-level "auto-tasks" is that you could have targets that you -wouldn't- want/need to have all these run when you're running those targets. For example, I have a "usage" target that prints out a list of (some of) the targets and what they do (similar to the Ant command flag -projecthelp, but not exactly). It doesn't depend on anything being run before it or after it. If, say, I had a project-level "success" specification that sent mail, I certainly wouldn't want that happening every time a "build" succeeded, since a "build" can be something as simple as running 'ant usage' -- so I wouldn't actually be able to use "success" for sending mail afterall, or for much of anything else either. Same for the others -- I wouldn't be able to use them, since they wouldn't always apply.
I'm not saying they shouldn't be availabe just because I couldn't use them -- just pointing out a possible gotcha.
Good points.
I was most concerned with tasks that have to be executed at the beginning (or end) of every build (i.e. <tstamp/>), and the maintenance issues of dozens (possibly hundreds) of targets that are all required to have the same dependency. Obviously any kind of "auto-task" would have to be benign and appropriate to every kind of build you'd ever want to do.
And, of course, with every new feature comes a new command line argument. ;)
It wouldn't be difficult to add a '-noauto' switch to Main. You can always regain control since the exact same effect could be accomplished by adding the auto-task names into the list of targets you want to build: 'Ant deploy' would be identical to 'Ant -noauto init deploy cleanup'
James
__________________________________ James Bucanek <mailto:[EMAIL PROTECTED]>
