I tried to add a new task named "Get" via the file (property-style) mechanism. The Taskdef task did not tell me about the name clash with the existing built- in task "Get". Instead, I learned at the invokation of the Task: "Class org.apache.tools.ant.taskdefs.Get doesn't support the "ref" attribute." (ref is a special attribute of my custom Get task) I would suggest that Ant should warn about name clashes.
Can you send me a build file that gives this error. I think I know what is happening but I'd like to make sure.
Created attachment 466 [details] here is a small demonstation project
Created attachment 596 [details] Patch to Project.java for bug# 3205
Attachment 596 [details] contains patch for this. In the addTaskDefintion() method of Project.java, I check first for the existence of a task by that name in the taskClassDefinitions hashtable. If it exists, I throw a BuildException. The question remains, however, whether this is the desired behavior. It makes it impossible to override tasks with others of the same name. This could be made conditional on an "override" attribute on the <taskdef> element.
No this is not the desired behaviour. You should be able to override inbuilt tasks. A better fix may be to just always defer task creation by commenting out this line in ProjectHelper // task = project.createTask(tag); That works OK but I haven't worked through any consequences yet.
Nightly build 2001-10-20 will now at least print a warning, but it won't fix Andreas original problem (the instance corresponding to <get> will be created before the taskdef has been evaluated, so the old definition wins). Workaround is to move the <taskdef> outside of a <target>. Conor, your proposed patch would break the reference mechanism where scripts or other tasks want to access task instances that have not been executed yet.