ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 10904] New: - replacement tasks (for those invalidated when taskdef is redefined) don't have children!
Date Wed, 17 Jul 2002 16:23:10 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10904>.
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:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message