You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by William Uther <wi...@cs.cmu.edu> on 2000/03/03 01:39:48 UTC
on multiple sub-projects
Hi all,
I had just given up hope on a <ForEach /> and started to implement
includes="" functionality in the <Ant > task when I came across a problem.
So you can view this email in one of two ways:
i) a call for help in designing a task that uses the 'preferred'
functionality.
ii) an example of why it can be nice to separate the 'ForEach'
functionality from the individual tasks.
Anyway, on with the story.
The <Ant /> task handles <property > tags. At the moment it does this as
follows:
> public Task createProperty() {
> Property p=(Property)p1.createTask("property");
> p.setUserProperty(true);
> properties.addElement( p );
> return p;
> }
where 'p1' is a Project - the sub-project we'll be calling. (This works
because init() is called after setXxxx() is called for arguments, but
before createXxxx() is called for elements. The init() method can create
the sub-project.)
As you can see it creates the required 'property' task using the
sub-project it will call. This will break in two ways with the
inlcludes="" functionality. i) we wont have the sub-projects yet, because
the includes information is not complete yet. ii) we want to intialize the
property for each sub-project, not just one of them. Conceptually we want
to return a list of objects that all get initialized from the same
information.
Can anyone see a neat way to implement this? (without using nested tasks -
that would make it trivial.)
My current thought is to make a 'pseudoProperty' object that stores the
data. This would be used to create the true property objects in the
sub-project during the execute() method.
This means that the interface to the pseudoProperty method is going to have
to be kept in sync with the true property interface manually. I'd really
like a way around that.
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.
Thoughts?
\x/ill :-}
P.S. This only seems to be a problem for tasks that want to use nested
tags and MatchingTask. I seem to have stumbled upon the only Task that
currently uses nested tags except for MatchingTask. sigh.
Re: on multiple sub-projects
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> The <Ant /> task handles <property > tags. At the moment it does this as
> follows:
>
> > public Task createProperty() {
> > Property p=(Property)p1.createTask("property");
> > p.setUserProperty(true);
> > properties.addElement( p );
> > return p;
> > }
And if we make properties which are global, then this is wrong. Property
would no longer be a task, but something that was parsed and set on the
project object iteself.
When did this change get made? Yuck.
Project.setProperty(name, value)
Project.getProperty
This is the only API for properties there should be. Let me draw out a
psuedo DTD (even though the design of Ant prevents a formal DTD from being
used) that explains how build.xml file was designed to be structured:
<!ELEMENT project (taskdef*, property*, task*)>
<!ELEMENT taskdef (EMPTY)>
<!ATTLIST taskdef
name CDATA
class CDATA)>
<!ELEMENT property (EMPTY)>
<!ATTLIST property
name CDATA
value CDATA)>
<!ELEMENT task (ANY)>
<!ATTLIST task (ANY)>
As you can see, it wasn't an intent of mine to make a property task, but for
properties to be project scoped. I propose to take it back to that.
.duncan
Re: on multiple sub-projects
Posted by co...@eng.sun.com.
> 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.
Ant works fine the way it is. If it works - please don't "fix" it. If what
you want requires a different semantic - create your own task ( you can
extend ant if you want).
> > 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.
Then implement another framework that supports all that if you need that -
but please don't call it ant.
You can still use all ant tasks.
There is nothing wrong with calling the tasks from a scripting language or
from java.
Costin
Re: on multiple sub-projects
Posted by William Uther <wi...@cs.cmu.edu>.
--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 :-}
Re: on multiple sub-projects
Posted by co...@eng.sun.com.
> 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 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?
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.
Please don't say that this is the just to implement variables.
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.
Costin