A task does not necessarily have to persist values that are set via the
setters into internal matching member variables, so I'm pretty sure
that an
XML serialization of an instantiated task cannot reliably give you back
the
state that was used to construct it. Thats just the nature of Ant 1.x.
Maybe what Jose Alberto mentioned about UnknownElement would work for
Ant
1.x - I don't know.
Perhaps this is different in Ant2 though.
That is the crux of the problem I face. I don't see any reason not to
provide the required accessors. I know that simple values like the
message attribute of Echo differ from say a classpath setting, but it
should be possible to provide a getClasspath method that returns the
Path.
I'm guessing the reason for only making an execute method required was
so
that someone could turn an existing class into an Ant task very easily
without having to implement an interface (although this should have
been the
way it was done, IMO) or break the inheritance hierarchy with by
subclassing. It allows a task to have zero dependency on Ant's classes,
which is a nice thing though.
I agree, providing accessors will not impact the dependency rules
either. I don't know much about the plans for Ant2, do people think
this would be a nice feature to have in that release or is there no
place for such functionality in Ant?
-John K
Erik
----- Original Message -----
From: "jbjk" <[EMAIL PROTECTED]>
To: "Ant Developers List" <[EMAIL PROTECTED]>
Sent: Friday, March 22, 2002 7:08 AM
Subject: Re: Exporting a Project Instance
The approach I was considering taking was getting the
taskdefs from the Project and the properties file. Then
the element names can be retrieved using the tasks class.
This means that tasks that do not extend Task will also
be handled.
The responses in this thread have all been with regards
to the implementation detail. Do people think that this
is a good idea?
If the pattern for a task was extended so each task must
have accessors then using reflection would be the way to
go.
What was the reason for only requiring tasks to have an
execute method? I don't think it would be an unreasonable
development burden for accessors to be required.
-John K
On Fri, 2002-03-22 at 01:06, Erik Hatcher wrote:
----- Original Message -----
From: "stephan beal" <[EMAIL PROTECTED]>
On Friday 22 March 2002 00:28, [EMAIL PROTECTED] wrote:
I have identified two approaches to achieve this. One is to get all
tasks to implement a toXML method. These methods would return an
XML
String representing that task instance. This obviously requires a
lot
of code changes.
With a serialize-to-xml framework it becomes pretty simple. i know
one
exists
in Java, but i can't remember the name.
I don't think its quite that simple.... how would such a framework get
attribute values and such to reconstruct the XML? There are typically
no
getters on Ant tasks to return back attributes and sub-elements.
And also, keep in mind that an Ant task does not necessarily extend
Task....
the only requirement to being an Ant task is implementing an execute()
method!
Erik
--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:ant-dev-
[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:ant-dev-
[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:ant-dev-
[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:ant-dev-
[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
