DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10904 replacement tasks (for those invalidated when taskdef is redefined) don't have children! Summary: replacement tasks (for those invalidated when taskdef is redefined) don't have children! Product: Ant Version: 1.5 Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Core tasks AssignedTo: ant-dev@jakarta.apache.org ReportedBy: mnewcomb@tacintel.com Scenario: You have a bunch of subprojects which all 'include' a common-build.xml file to get some common properties and taskdefs. Now, you have an overall project file which includes the 'common-build.xml' file and uses 'Ant' tasks to call all the subprojects. Problem: Upon examining the Ant.java task, each sub-project inherits all of the the containing projects data types and task defs. First question: Why is this the default behavior? Should there be some properties similary to inheritAll like inheritTaskDefs and inheritDataTypes? By inheriting the task defs, a bug is revealed in how taskdefs are invalidated based upon the implementing class. The containing build file includes the common-build.xml file and defines the task first, but each sub-project build file does the same thing and when it is done in the sub-project, the task is already defined, but since it was loaded from a different class loader, it is not equal and therefore all the tasks based upon the taskdef are invalidated. Actual taskdefed objects are created because when the parser encounters the non- core element, it finds it is in the set of defined tasks and therefore goes through the proper rigamorall of setting all the sub-elements and stuff. Now when the task (based upon the taskdef) is finally executed, it sees that it is invalid and asks Task.java.getReplacement() for an UnknownElement to take its place. Then when the UnknownElement is maybeConfigure() it will look up and instantiate the actual Task that it wraps. This works for the most part, but it has one major flaw, the invalidated tasks children are not added to the new UnknownElement object and therefore maybeConfigure() doesn't have any children to configure and that causes tasks requiring children to fail! Solution: The best solution to this problem would be for the Project to re-parse the task element from the project file from which the invalidated task was generated. Without re-parsing the task element, its impossible for the the invalidation process to work properly. Solution Problems: How do we re-parse the task element? We can't because we process the file in its entirety using a SAX parser. Workaround: The only real work around is to do a taskdef in each sub-project. I don't see this is being a good solution because it leaves task invalidation broken. Ideas? Michael -- To unsubscribe, e-mail: For additional commands, e-mail: