ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Exporting a Project Instance
Date Fri, 22 Mar 2002 14:08:33 GMT
> 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 

> 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" <>
> To: "Ant Developers List" <>
> 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" <>
>>>> On Friday 22 March 2002 00:28, 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
>>>>> 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:
> <>
>>> For additional commands, e-mail:
> <>
>> --
>> To unsubscribe, e-mail:   <mailto:ant-dev-
>> For additional commands, e-mail: <mailto:ant-dev-
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-
> For additional commands, e-mail: <mailto:ant-dev-

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message