ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Uther <will+...@cs.cmu.edu>
Subject Re: <Ant /> on multiple sub-projects
Date Fri, 03 Mar 2000 19:05:03 GMT
--On Thu, Mar 2, 2000 11:39 PM -0800 costin@eng.sun.com wrote:

>> Essentially the problem I see myself encountering is that I need to embed
>> the <ForEach > functionality into the <Ant > task.  The sub-task
>> implementation I posted previously kept the DOM around to re-make the
>> subtasks each iteration.  I'm going to have to do the same thing, but
>> without the guarantee that I'm capturing all the information.
> 
> Please, don't !
> Keeping DOM around is wrong - it's redundant information, and it will put
> too much weight on the framework. 

I guess the problem is that the current <Ant /> task already has sub-tasks.
It uses the createProperty() method to create a task in the sub-project it
will run.

If you want to have multiple sub-projects (even using the 'preferred'
includes="" syntax) then you need to initialize multiple Property objects
from each <property> tag; one for each of the sub-projects.

I can see a few possible solutions:

 - remove the ability of the <ant /> task to have <property /> elements.
 - store the <property /> information in an object using the current
interface, then initialize a new Property object from that storage object
during each iteration.  This has the disadvantage that it makes <property>
tags in the <ant> task different from <property> tags elsewhere.  Changes
in one have to be propogated to the other manually.  This solution is
better if you rename the element in <Ant> so there is no expectation that
it is the same as a standard property task.
 - Keep some generic form of the information around that could be used to
initialize the property tags.  This could be in DOM form or in any other
form.  You can then initialize the property objects from this information
and be sure you haven't lost anything.

> I can't understand what's wrong with reading the XML and creating Java
> objects ??? Why do you need to keep the information after that in memory?

Because, using the includes="" syntax, I do not know how many property
objects to create until after the createProperty() method has been called.
And even if I did, createProperty() can only return one of them for
ProjectHelper to initialize.

> DOM is a solution for a different problem - why keeping the XML document
> in 2 different forms - the Java object tree and DOM ( or any equivalent )?
> SAX is more than enough - and it's the logical solution.

Because, if we keep the <property> subtask and try to implement looping,
you need the information after ProjectHelper has finished.

> Please don't say that this is the just  to implement variables. 

This currently has nothing to do with variables.  It has to do with the
fact that the <Ant /> task has a sub-task, and I want to iterate over
multiple folders.  I can either drop out the sub-task (removing current
functionality), or keep around the information to re-initialize it each
iteration.

> All current Ant tasks work fine with the constants ( or whatever
> <property> is - it is set before project execution  and doesn't change
> after). If you need more - please don't change everything, maybe you can
> use a scripting language that has a clear notion of variables, or your own
> API that can get/set attributes. 

This has nothing to do with variables or constants.  The element I'm
talking about is called <property>, but any "deep-xml" element that needs
to be re-initialized for each file in an includes="" list will have the
same difficulty.

later,

\x/ill        :-}



Mime
View raw message