ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: Exporting a Project Instance
Date Sat, 23 Mar 2002 00:25:18 GMT

> -----Original Message-----
> From: []
> Sent: Saturday, 23 March 2002 12:09 AM
> To: Ant Developers List
> Subject: Re: Exporting a Project Instance
> > 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.

It's an awful lot of code for us to add (and write test cases for, and
maintain, and document, and answer questions about, and ..), for a rather
questionable result.

Even if the use case justified the effort, and the impact on every task
writer who would have to write a bunch of code that they don't want or need,
you've still got the question of the quality of the result.  The
configuration that the tasks receive has been interpreted and converted.
This means that all the ${} property references have been resolved, relative
paths converted to absolute paths, references resolved, and so on.  The XML
that would get spat out would be pretty much useless.

I'm -1 on trying to extract state out of configured tasks and data-types.

Having said that, I think we do have a reasonable solution, in the longer
term.  Namely, the separation of project model from the task objects.  There
is some discussion going on about how we might do this in ant 1.x, and it
will certainly be available in ant 2 (both mutant and myrmidon have
separated out the project model).

So, what you would do is, rather than instantiate, configure and execute the
task objects directly, you would build the model for the project (like a
DOM), and then could either persist the model to an XML file (or whatever
representation you liked), or execute it in the ant engine.


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

View raw message