>>>>> "JDD" == James Duncan Davidson <[EMAIL PROTECTED]> writes:
First of all, thanks for putting this together. Having this kind of document will help all the newbies (including myself) to see what Ant is intended to be and what not. JDD> After all dependancies have been executed, the current target JDD> has its task list examined and the tasks within that list are JDD> configured and executed in sequential order. [...] JDD> [...] It is JDD> important that this configuration happens just before execution, JDD> and after execution of the previous task, so that any JDD> configuration information that depends on properties can be JDD> properly conveyed. Yes, this will definitively add to the understandability goal. It took me quite some time to note that this is not the way it works rigth now. JDD> The other part that needs work is what happens inside the JDD> taskimpl areas. I like the way attributes and nested elements are handled right now. Using reflection for the createXXX methods (or addText in the case of CDATA areas) should decouple the runtime from XML good enough. JDD> $install_dir/ext/tasktype1.jar JDD> /META-INF/taskdef.xml JDD> The /META-INF/taskdef.xml file defines the task name and the JDD> task class. JDD> When ant starts, it scans the /ext dir, loads in all tasks and JDD> makes them available to the runtime. It doesn't do this by JDD> placing them on the classpath in the ant.sh script, but by using JDD> JAR class loaders. I really like the idea of the ext directory but would prefer a way to specify which extension to load when starting ant. I can easily imagine extensions that are not used in every project. Then again as long as classes are only loaded from the JAR files when the corresponding task is actually executed we only get a little runtime hit at startup. JDD> When ant is installed, a ant.xml file is placed into the JDD> user's user.dir that defines where the ant installation is. If JDD> this isn't present and ant is started, it should ask the user.
