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>
|