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/02/25 02:07:08 UTC
Subtasks within tasks
Hi,
The current ANT allows you to have properties within tasks, and these can
be arbitrarily nested, but each one requires a createXxxx() method to
return an object that goes along with that XML property. This means you
can't have general sub-Tasks. You'd have to make a createXxxx() method for
each task - not feasable.
So, I've implemented some changes that allow arbirary sub-Tasks. There
is a new interface: SubTaskable which has an addSubTask(Task) method. When
a property is encountered for which there is no createXxxx() method, the
element is checked to see if it implements SubTaskable. If it does then a
task with the appropriate name is created and added using the
addSubTask(Task) method.
To keep things clean I also modified Target and Task slightly. Target
now implements SubTaskable. The Task.setTarget(Target) has been changed to
Task.setTarget(SubTaskable). I also deprecated the Target.addTask(Task)
method. It does the same thing as the new addSubTask(Task) method. I
didn't use addTask(Task) in the SubTaskable interface because that might
conflict with an attribute. With it's two capitals, addSubTask() cannot.
I've attached diffs for ProjectHelper.java, Task.java and Target.java.
I've attached the complete SubTaskable.java. I've also attached a task,
SubTaskTest.java, that simply executes each of its subtasks in order.
later,
\x/ill :-}
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> If we want ANT to really be able to succeed in the large as well as the
> small
> we will need will eventually need some way to define new tasks by
> composing
> existing tasks. In any type of composition we will need some way pick
> between alternatives.
There's a limit at which I'd personally like to see Ant go to. Yes, at some
point, the simple model it uses will run out of steam. But that's a very
large point. The JDK is increadibly huge, but I'm pretty sure that I could
build it with a modified javac taskdef that split the total number of
classes to compile into manageably sized chunks. Everything else about that
build would require memory and some processor speed. So at least to that
level I disagree with you that we'll have to put any amount of turing
completeness into ant to manage larger projects.
What would help is a way of building antfiles that was GUI based so that you
aren't stuck typing in XML. A simple Jtree based GUI along with addTask,
removeTask buttons would go a ways there.
> 1) A way to define new tasks by naming other tasks:
>
> <taskdef .... >
> <task1.../>
> <task2...> ... <task2>
> <taskdef>
So if you did that, how do you propose the reflection of properties would
work? Especially if there was a namespace collision. In addition, even if
that weren't a problem, I don't see what you've done that you can't do with
with calling task1, task2 in order. It's not quite like chemistry where 2xH
+ 0 = something different. :)
> 2) Something like lisp's mapcar so that one can apply
> the same task to a sequence of values. So one can
> say things like apply this tasks to all this values.
> This is declarative in the sense that there is no order
> involved in this application, in principle one could
> apply the tasks in parallel or backwards or whatever.
Reasonably interesting. But I don't think that the relative complexity of
adding such a feature would really be worth it when it would be just as easy
to call out what you needed.
.duncan
----------------------------------------------------------------------
James Duncan Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do();
Re: Big change
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Ludovic Claude wrote:
>
> Hello,
>
> I've made some major changes in Ant, you can test them by dowloading the
> following
> distribution. Basically, Ant now uses the Configuration from the Avalon
> framework
And magically those interfaces are going to be modified...
Puff.... :(
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Big change
Posted by Ludovic Claude <lc...@websitewatchers.com>.
Hello,
I've made some major changes in Ant, you can test them by dowloading the
following
distribution. Basically, Ant now uses the Configuration from the Avalon
framework
(http://java.apache.org/framework/index.html), Sax parser can be used (including
Xerces),
properties are dynamically evaluated and the controversial ForEach is there,
plus lots of other small changes.
According to my tests, it's fully compatible with the existing ant.
Now i guess that some people will not be happy with the changes, and that a vote
will be required to merge this change, but i've simply listened to what people
asked for
on the mailing list and done it...
You can download it and test it from:
http://www.ringsys.co.uk/opensource/Ant-1.0-experimental.zip
http://www.ringsys.co.uk/opensource/ant-diffs.txt
Full list of change is:
- Include a subset of the Avalon project (Java Apache Framework), with the
Configuration abstraction and an xml loader based on SAX. You get better error
reporting from the xml parser, and you can choose with parser to use (projectx,
xerces,...).
- Project, Target, Task become Configurable classes, and they can initialize
themselves
from their configuration
- An helper class (TaskHelper) has been created to configure easily the tasks
and
also to use introspection only once per class
- All tasks are still created at init but their properties are set just before
their
execution, thus the evaluation of ${NAME} becomes dynamic
<property name="i" value="1" />
<echo message="Value = ${i}" />
<property name="i" value="2" />
<echo message="Value = ${i}" />
<property name="i" value="3" />
<echo message="Value = ${i}" />
will print
Value = 1
Value = 2
Value = 3
instead of
Value = 1
Value = 1
Value = 1
as it was before.
- Tasks and beans can now have setters with String, boolean, int and float
parameter types.
- Each task implementing BaseTask can use local properties:
<simpletask param1="foo" param2="${bar}" >
<property name="bar" value="foo2" />
</simpletask>
Note that the value of param2 is foo2
- Each task (implementing BaseTask) can use nested parameters to define its
parameter list
<javadoc scr="." dest="/doc" />
can be written also as
<javadoc>
<param name="src" value="." />
<param name="dest" value="/doc" />
</javadoc>
It might be useful for javadoc and other tasks with a very long list of args
--
_____________________________________
Web Site Watchers Ltd
212 Piccadilly,
London W1V 9LD
United-Kingdom
Telephone: +44 (0)171 917 6255
Fax: +44 (0)171 439 0262
http://www.websitewatchers.co.uk
lc@websitewatchers.com
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> My idea of in the large, was not reffering to the amount of files to Javac
but
> to the amount of tasks required of a large project in general. I can agree
that
> if the goal is just Java we may not need too much more because we have
> made the javac task so powerful that overcomes the shortfalls of ant as it
is
> today.
Ah, ok. Thanks for the clarification.
> But, could we use and for building Apache (the webserver?), a tool for
that
> would
> have to take care of a more broad set of issued. My point is that ant has
the
> potential
> to break the current java "glass ceilling". And being a more declarative
way to
> define
> builds that what we have with MAKE today which I agree is quite a monster.
I don't know though. Taking on C based projects is quite a beast and I don't
think that we can make something that, in the end, will be better than
autoconf/make.
> > What would help is a way of building antfiles that was GUI based so that
you
> > aren't stuck typing in XML. A simple Jtree based GUI along with addTask,
> > removeTask buttons would go a ways there.
>
> GUIs are fine, but not the end of everything.
Of course not. Note that I wasn't proposing functionality in the GUI that
wouldn't be available, just making it nicer.
> With respect to the second part of your comment, I just have
> to mention that had such an attitude prevailed we would be writing
assembly
> language.
> Do you believe in code reuse? modularity? If someone composes a task is
because
> he plans to perform the same group of operations over and over and it
makes more
> sense
> writing it just once.
Of course I do. Silly. I work only with OO languages now adays 'cuz I hate
what came before for most things. The statement was only about the specific
example given. I didn't see how combinatorialy it would be any better than
the elements standalone. This doesn't mean that I have that attitude about
everything. Obviously Ant itself is an exercise in fairly decent OO what
with it's interfaces, abstract classes, and dynamic class.fornaming :)
----------------------------------------------------------------------
James Duncan Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do();
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by Jose Alberto Fernandez <jo...@us.oracle.com>.
James Duncan Davidson wrote:
> > If we want ANT to really be able to succeed in the large as well as the
> > small
> > we will need will eventually need some way to define new tasks by
> > composing
> > existing tasks. In any type of composition we will need some way pick
> > between alternatives.
>
> There's a limit at which I'd personally like to see Ant go to. Yes, at some
> point, the simple model it uses will run out of steam. But that's a very
> large point. The JDK is increadibly huge, but I'm pretty sure that I could
> build it with a modified javac taskdef that split the total number of
> classes to compile into manageably sized chunks. Everything else about that
> build would require memory and some processor speed. So at least to that
> level I disagree with you that we'll have to put any amount of turing
> completeness into ant to manage larger projects.
>
My idea of in the large, was not reffering to the amount of files to Javac but
to the amount of tasks required of a large project in general. I can agree that
if the goal is just Java we may not need too much more because we have
made the javac task so powerful that overcomes the shortfalls of ant as it is
today.
But, could we use and for building Apache (the webserver?), a tool for that
would
have to take care of a more broad set of issued. My point is that ant has the
potential
to break the current java "glass ceilling". And being a more declarative way to
define
builds that what we have with MAKE today which I agree is quite a monster.
>
> What would help is a way of building antfiles that was GUI based so that you
> aren't stuck typing in XML. A simple Jtree based GUI along with addTask,
> removeTask buttons would go a ways there.
GUIs are fine, but not the end of everything.
>
> > 1) A way to define new tasks by naming other tasks:
> >
> > <taskdef .... >
> > <task1.../>
> > <task2...> ... <task2>
> > <taskdef>
>
> So if you did that, how do you propose the reflection of properties would
> work? Especially if there was a namespace collision. In addition, even if
> that weren't a problem, I don't see what you've done that you can't do with
> with calling task1, task2 in order. It's not quite like chemistry where 2xH
> + 0 = something different. :)
>
Hey, I do not have all the answers :) at this point I am just dropping ideas for
we all to consider.
With respect to the second part of your comment, I just have
to mention that had such an attitude prevailed we would be writing assembly
language.
Do you believe in code reuse? modularity? If someone composes a task is because
he plans to perform the same group of operations over and over and it makes more
sense
writing it just once.
>
> > 2) Something like lisp's mapcar so that one can apply
> > the same task to a sequence of values. So one can
> > say things like apply this tasks to all this values.
> > This is declarative in the sense that there is no order
> > involved in this application, in principle one could
> > apply the tasks in parallel or backwards or whatever.
>
> Reasonably interesting. But I don't think that the relative complexity of
> adding such a feature would really be worth it when it would be just as easy
> to call out what you needed.
>
This will allow for something more declarative than coding than for loops.
The idea here would be to be able to say "apply to all files include...
exclude...",
and things like that. Notice that today we have that functionality only at
specific taskdefs but not a general facility available to tasks. So we could
have
something like:
Here the property "file" is set to the value of the file on each application.
<apply2files include="...." exclude="...." >
<task1 param="${file}" ....>
<task2 ......>
</apply2files>
>
> .duncan
>
> ----------------------------------------------------------------------
> James Duncan Davidson duncan@eng.sun.com
> Java + XML / Portable Code + Portable Data !try; do();
--
------------------------------------------------------------------------
Jose Alberto Fernandez 500 Oracle Parkway, M/S 9op4
Development Manager Redwood Shores, CA 94065
ORACLE Corp. Phone: (650) 506-8830
Java Products Group Fax: (650) 506-7303
Languages & Obj-Relational Tech Email: jofernan@us.oracle.com
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> If we want ANT to really be able to succeed in the large as well as the
> small
> we will need will eventually need some way to define new tasks by
> composing
> existing tasks. In any type of composition we will need some way pick
> between alternatives.
There's a limit at which I'd personally like to see Ant go to. Yes, at some
point, the simple model it uses will run out of steam. But that's a very
large point. The JDK is increadibly huge, but I'm pretty sure that I could
build it with a modified javac taskdef that split the total number of
classes to compile into manageably sized chunks. Everything else about that
build would require memory and some processor speed. So at least to that
level I disagree with you that we'll have to put any amount of turing
completeness into ant to manage larger projects.
What would help is a way of building antfiles that was GUI based so that you
aren't stuck typing in XML. A simple Jtree based GUI along with addTask,
removeTask buttons would go a ways there.
> 1) A way to define new tasks by naming other tasks:
>
> <taskdef .... >
> <task1.../>
> <task2...> ... <task2>
> <taskdef>
So if you did that, how do you propose the reflection of properties would
work? Especially if there was a namespace collision. In addition, even if
that weren't a problem, I don't see what you've done that you can't do with
with calling task1, task2 in order. It's not quite like chemistry where 2xH
+ 0 = something different. :)
> 2) Something like lisp's mapcar so that one can apply
> the same task to a sequence of values. So one can
> say things like apply this tasks to all this values.
> This is declarative in the sense that there is no order
> involved in this application, in principle one could
> apply the tasks in parallel or backwards or whatever.
Reasonably interesting. But I don't think that the relative complexity of
adding such a feature would really be worth it when it would be just as easy
to call out what you needed.
.duncan
----------------------------------------------------------------------
James Duncan Davidson duncan@eng.sun.com
Java + XML / Portable Code + Portable Data !try; do();
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by Jose Alberto Fernandez <jo...@us.oracle.com>.
James Duncan Davidson wrote:
>
> > <switch name="os.name">
> > <case value="Mac OS">
> > <javac ..... />
> > </case>
> > <case value="Win*">
> > <javac ..... />
> > </case>
> > <deafult>
> > <Deltree ..... />
> > </default>
> > </switch>
>
> The problem that I have with this is that it introduces logic into the
> antfile. It was an explicit design goal of mine when I first wrote ant for
> the files to be totally declaritive and *all* logic occurs in the task. If
> you want to write specialized logic, you can -- it's easy enough to add
> tasks via the <taskdef...> -- now, if the group wants to change course on
> that, that's something I can't control, but I won't welcome it.
>
There is nothing declarative about what you are saying. You do not write
something more declarative by constantly adding more words to the
language.
How can anyone understand what you are declaring if you cannot
understand
the words (<taskdef...>).
Something is declarative if you can understand it based on a mostly
limited
number of concepts that one can combine to achieve the required meaning.
To me, once we have some critical mass, additional <taksdef...> should
only
be necessary when trying to use ANT on some new environment, something
different from bilding (java) applications. In principle, any task that
requires a topological ordering at its hard, can use the ANT machinery
but most probably a completely different vocabulary (<taskdef...>).
> This means that I would prefer not to see anything like an if/then/else,
> for, or switch implemented in this fashion. If you want to build logic, do
> it in Java. If you want to describe the project, do it in XML.
>
> .duncan
If we want ANT to really be able to succeed in the large as well as the
small
we will need will eventually need some way to define new tasks by
composing
existing tasks. In any type of composition we will need some way pick
between alternatives.
Now, I may agree with you that <select> <if> <foreach> may not be the
right
declarative means and that we would be polluting ANT with the evils of
procedural programming. I would suggest a different set of composing
operations (more declarative in my opinion).
1) A way to define new tasks by naming other tasks:
<taskdef .... >
<task1.../>
<task2...> ... <task2>
<taskdef>
2) Something like lisp's mapcar so that one can apply
the same task to a sequence of values. So one can
say things like apply this tasks to all this values.
This is declarative in the sense that there is no order
involved in this application, in principle one could
apply the tasks in parallel or backwards or whatever.
3) Some way to select between alternatives, here something
like a pattern matching to define different cases.
Now with this three concepts we can do very sofisticated
things in a very declarative manner. Notice the difference
between this and MACROS in the sense of make. Macros are
not declarative at all because in general you cannot define
what they mean until you expand them fully. Here every construct
is meaninful in its own right.
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by Stefano Mazzocchi <st...@apache.org>.
Pierpaolo Fumagalli wrote:
>
> James Duncan Davidson wrote:
> >
> > The problem that I have with this is that it introduces logic into the
> > antfile. It was an explicit design goal of mine when I first wrote ant for
> > the files to be totally declaritive and *all* logic occurs in the task. If
> > you want to write specialized logic, you can -- it's easy enough to add
> > tasks via the <taskdef...> -- now, if the group wants to change course on
> > that, that's something I can't control, but I won't welcome it.
>
> I wouldn't welcome them either... The lack of programmable project logic
> is, imvho, the REAL power of Ant, making its buildfiles easy to
> understand, debug, and write. Adding those components will, in the long
> term, transform ANT into an elephANT :)
>
> > This means that I would prefer not to see anything like an if/then/else,
> > for, or switch implemented in this fashion. If you want to build logic, do
> > it in Java. If you want to describe the project, do it in XML.
>
> Perfectly agreed... Otherwise we'll come up with just another XMLized
> version of MAKE, at the end...
+345!!!
Ant is _NOT_ and never should be make4j or something like that.
Make, IMVHO, comes from _years_ of thinking "the more powerful the
better". This is what I've been naming "the Flexibility Syndrome".
I loved Ant because it allows you to do whatever you want but with
_clear_ constraints.
I could tell it was created by James because I love his way of reasoning
which matches mine very much: symmetry is not, alone, a good reason to
implement something.
So, let's put an end on this and remove the logic from the build files.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by Pierpaolo Fumagalli <pi...@apache.org>.
James Duncan Davidson wrote:
>
> The problem that I have with this is that it introduces logic into the
> antfile. It was an explicit design goal of mine when I first wrote ant for
> the files to be totally declaritive and *all* logic occurs in the task. If
> you want to write specialized logic, you can -- it's easy enough to add
> tasks via the <taskdef...> -- now, if the group wants to change course on
> that, that's something I can't control, but I won't welcome it.
I wouldn't welcome them either... The lack of programmable project logic
is, imvho, the REAL power of Ant, making its buildfiles easy to
understand, debug, and write. Adding those components will, in the long
term, transform ANT into an elephANT :)
> This means that I would prefer not to see anything like an if/then/else,
> for, or switch implemented in this fashion. If you want to build logic, do
> it in Java. If you want to describe the project, do it in XML.
Perfectly agreed... Otherwise we'll come up with just another XMLized
version of MAKE, at the end...
Pier
--
--------------------------------------------------------------------
- P I E R -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org> <http://www.betaversion.org/~pier/>
--------------------------------------------------------------------
- ApacheCON Y2K: Come to the official Apache developers conference -
-------------------- <http://www.apachecon.com> --------------------
Re: Using bash scripts on Windows
Posted by Scott M Stark <st...@attglobal.net>.
If you don't think there is sufficient utility don't bother. Its not a big
deal.
----- Original Message -----
From: "James Duncan Davidson" <ja...@eng.sun.com>
To: <an...@jakarta.apache.org>
Sent: Saturday, February 26, 2000 3:20 PM
Subject: Re: Using bash scripts on Windows
> I used to use bash, then ksh on my windoze machines. But finally I got
tired
> of fighting all teh sort of imcompatibilities involved. Anyway, I'm ok
with
> this going into a contrib type area, but I think that we need to keep the
> number of entry points in the main distrubution to a minimum, esp since
most
> windows users are using plain ol cmd.exe
>
> .duncan
>
Re: Using bash scripts on Windows
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> I use bash on all windows platforms rather than the cmd shell. The only
> problem
> I ever have is java classpaths defined using ':' as the separater. Its a
> simple change
> to accomdate use of the ';' separater for the bash/NT situation. Below is
a
> modified bootstrap.sh that works with bash under unix and NT. Is it
> worthwhile
> to add this to the distribution?
I used to use bash, then ksh on my windoze machines. But finally I got tired
of fighting all teh sort of imcompatibilities involved. Anyway, I'm ok with
this going into a contrib type area, but I think that we need to keep the
number of entry points in the main distrubution to a minimum, esp since most
windows users are using plain ol cmd.exe
.duncan
Using bash scripts on Windows
Posted by Scott M Stark <st...@attglobal.net>.
I use bash on all windows platforms rather than the cmd shell. The only
problem
I ever have is java classpaths defined using ':' as the separater. Its a
simple change
to accomdate use of the ';' separater for the bash/NT situation. Below is a
modified bootstrap.sh that works with bash under unix and NT. Is it
worthwhile
to add this to the distribution?
# OS independent bash script
if [ -f $HOME/.antrc ] ; then
. $HOME/.antrc
fi
if [ -z "${JAVA_HOME}" ] ; then
echo JAVA_HOME must be set
exit 1
fi
# Windows defines an OS env variable
if [ -z "${OS}" ] ; then
CPS=":"
else
CPS=";"
fi
SRCDIR=src/main/org/apache/tools
CLASSDIR=classes
CLASSPATH="${CLASSPATH}${CPS}${JAVA_HOME}/lib/classes.zip"
CLASSPATH="${CLASSPATH}${CPS}${JAVA_HOME}/lib/tools.jar"
CLASSPATH="${CLASSPATH}${CPS}lib/xml.jar${CPS}src/main${CPS}${CLASSDIR}"
mkdir -p ${CLASSDIR}
export CLASSPATH
echo CLASSPATH="$CLASSPATH"
javac -d "${CLASSDIR}" ${SRCDIR}/tar/*.java
javac -d "${CLASSDIR}" ${SRCDIR}/ant/*.java
javac -d "${CLASSDIR}" ${SRCDIR}/ant/taskdefs/*.java
cp src/main/org/apache/tools/ant/taskdefs/defaults.properties
${CLASSDIR}/org/apache/tools/ant/taskdefs
cp src/main/org/apache/tools/ant/parser.properties
${CLASSDIR}/org/apache/tools/ant
java org.apache.tools.ant.Main main
java org.apache.tools.ant.Main clean
if test ! -d bin; then mkdir bin; fi
cp src/bin/antRun bin
chmod +x bin/antRun
rm -rf ${CLASSDIR}
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> <switch name="os.name">
> <case value="Mac OS">
> <javac ..... />
> </case>
> <case value="Win*">
> <javac ..... />
> </case>
> <deafult>
> <Deltree ..... />
> </default>
> </switch>
The problem that I have with this is that it introduces logic into the
antfile. It was an explicit design goal of mine when I first wrote ant for
the files to be totally declaritive and *all* logic occurs in the task. If
you want to write specialized logic, you can -- it's easy enough to add
tasks via the <taskdef...> -- now, if the group wants to change course on
that, that's something I can't control, but I won't welcome it.
This means that I would prefer not to see anything like an if/then/else,
for, or switch implemented in this fashion. If you want to build logic, do
it in Java. If you want to describe the project, do it in XML.
.duncan
Re: Macro task (was: Subtasks within tasks)
Posted by James Duncan Davidson <ja...@eng.sun.com>.
> It would also be good to be able to define macros, for example
>
> <macrotask name="mymacro" properties="param1, param2" >
> <javac src="${param1}" ... />
> <copyfile src="${param2}" dest=... />
> </macrotask>
-1.
If you want to have a test of tasks executed, then set them up as a seperate
target that is depended on. Once again, my argument is that the design
intent was for the build.xml file to be totally declaritive and not contain
logic.
.duncan
Macro task (was: Subtasks within tasks)
Posted by Ludovic Claude <lc...@websitewatchers.com>.
William Uther wrote:
>
> Having a generic TaskContainer capability allows you to create tasks such
> as:
>
> <switch name="os.name">
> <case value="Mac OS">
> <javac ..... />
> </case>
> <case value="Win*">
> <javac ..... />
> </case>
> <deafult>
> <Deltree ..... />
> </default>
> </switch>
>
It would also be good to be able to define macros, for example
<macrotask name="mymacro" properties="param1, param2" >
<javac src="${param1}" ... />
<copyfile src="${param2}" dest=... />
</macrotask>
and you would use it with
<macro name="mymacro">
<property name="param1" value="..." />
<property name="param2" value="..." />
</macro>
A macro looks a lot like a target but it is not executed because it belongs to
the list of dependencies
but simply because somebody calls it.
Ludovic.
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by William Uther <wi...@cs.cmu.edu>.
--On Fri, Feb 25, 2000 12:03 AM -0800 costin@eng.sun.com wrote:
>> <switch name="os.name">
>> </switch>
>
> I was afraid of that....
I don't think I've ever managed to rate 'scary' before :).
> I think we should split the problem in 2:
>
> 1. How to deal with the case of
> <foo>
> <bar>
> </foo>
> Where we can't have createBar() ( because we want foo to support dynamic
> sub-elements, including elements defined at runtime with taskdef ).
>
> In your particular case, having foo implement an interface will work and
> it's a good solution, but I was thinking at the general case, when the
> child doens't have to be a task - this is not the only situation when you
> need a dynamic sub-element.
Ahhh, ok. Your previous suggestion makes much more sense now :).
from Costin's previous commment:
> For "<foo>":
>
> - first try createFoo()
> - if no such method is found, try to create a foo object ( based on
> existing taskdefs )
> - try addFoo( foo )
> - if no such method try addBar() where Bar is an interface implemented by
> foo ( or superclass).
I would suggest is moving from addFoo() and addBar() to just an
addElement(elt) method. Instead of using the method name to do the
specialization, you could use the type of the formal parameter. (e.g.
addElement(foo myFoo) vs addElement(bar myBar))
> 2. <case>, <macro>, etc. We need a lot of thinking before adding such
> thing in ant. The reason I asked "what is a sub-task/ task container"
> is simple - what you want is not a simple "patch" or incremental change,
> but a radical change in the ant architecture and idea.
Actually, from the perspective of someone who has just arrived, it looks
like a logical next step. Having looked at implementing it, I agree it
needs a change of semantics internally - but you can see the other thread
for that.
> Ant is not a programming language, and adding if and loop will make it a
> PL ( by Turing machine def). It's nothing wrong with inventing a new PL,
> it's just that many people like ant because it's simple and not yet
> another PL.
I am a strong believer in the KISS principle. I use java and not C++ :).
However, at present you cannot replace fairly simple makefiles with ANT
because it lacks this functionality. From the point of view of someone
looking for a cross-platform build utility this is somewhat frustrating.
You should make things as simple as possible, but no simpler. Right now
ANT falls into the 'too simple' category.
Adding if and loop will make ANT turing complete. However, from a KISS
standpoint there is a big difference between that and C++.
> I think both are very serious design issues, and I think we should wait
> and have a general agreement before adding them ( I'm -1 on both ).
Speaking of waiting, has anyone looked at those Mac patches I posted?
later,
\x/ill :-}
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by co...@eng.sun.com.
> <switch name="os.name">
> <case value="Mac OS">
> <javac ..... />
> </case>
> <case value="Win*">
> <javac ..... />
> </case>
> <deafult>
> <Deltree ..... />
> </default>
> </switch>
I was afraid of that....
I think we should split the problem in 2:
1. How to deal with the case of
<foo>
<bar>
</foo>
Where we can't have createBar() ( because we want foo to support dynamic
sub-elements, including elements defined at runtime with taskdef ).
In your particular case, having foo implement an interface will work and
it's a good solution, but I was thinking at the general case, when the
child doens't have to be a task - this is not the only situation when you
need a dynamic sub-element.
2. <case>, <macro>, etc. We need a lot of thinking before adding such
thing in ant. The reason I asked "what is a sub-task/ task container"
is simple - what you want is not a simple "patch" or incremental change,
but a radical change in the ant architecture and idea.
Ant is not a programming language, and adding if and loop will make it a
PL ( by Turing machine def). It's nothing wrong with inventing a new PL,
it's just that many people like ant because it's simple and not yet
another PL.
I think both are very serious design issues, and I think we should wait
and have a general agreement before adding them ( I'm -1 on both ).
Costin
Re: Tasks containing other tasks (was: Subtasks within tasks)
Posted by William Uther <wi...@cs.cmu.edu>.
> I have few problems with that particular solution:
Ok. Thanks for the comments. I think you must have misunderstood my
intent though, or else I've misunderstood your reply. I've re-ordered your
mail in my reply to try to clear that up.
> - What is a sub task anyway ? I can't figure what it will do. SubCopy?
A subtask is just a task contained within another task. Any task could be
a sub-task. It is just like a property, except that you will not know its
name at compile-time, so you cannot have a createXxxx() method. My patch
allows you to use any task in the system as a property. It does this NOT
by marking out the tasks that can be sub-tasks (you could do this
currently) but by marking out the tasks/property-objects that can contain
other tasks as sub-tasks.
I should have named the 'SubTaskable' interface 'TaskContainer'. (Just
made that name change in my code). The addSubTask() method should probably
be named addTask(), but I thought that would conflict with the attribute
addXxx() methods. What do you think?
Having a generic TaskContainer capability allows you to create tasks such
as:
<switch name="os.name">
<case value="Mac OS">
<javac ..... />
</case>
<case value="Win*">
<javac ..... />
</case>
<deafult>
<Deltree ..... />
</default>
</switch>
This couldn't be made under the current ANT unless you specifically added a
createJavac() method to the Case class. Using my code, the Case class
implements TaskContainer.
In detail; when ProjectHelper encounters the first <javac .... /> above, it
looks for a Case.createJavac() method, but none exists. It then looks to
see if Case implements TaskContainer. It does, so ProjectHelper creates a
new javac task and calls Case.addSubTask() with the new javac object.
Another example of a task requiring subtasks (Although this is not
currently possible because of the strange semantics of task
creation/execution):
<ForEach variable="i" list="subprojectA:subprojectB" separator=":">
<Ant dir="${i}" target="clean" />
<Ant dir="${i}" target="main" />
</ForEach>
> - it is specific to Tasks ( createSubTask, SubTaskable, etc ) - everything
> else in ant is using introspection and patterns.
You can view it as a generalization of the way that Targets currently work.
They do NOT use introspection. They use a single addTask(Task) method. No
introspection neccessary. Nor do I think introspection should be used
where another simple solution exists. Introspection moves errors from
compile-time to run-time, something I prefer to avoid.
> - it sound a bit to complex
Implementation or use?
It is simpler than your suggestion in both respects.
> If you have a particular task that needs this kind of sub-task we should
> try to find a pattern-based solution.
>
> In particular addXXX works fine in this case and doesn't require any
> interface ( and it's implemented in tomcat ):
I don't understand how you use a generic addXxx methods in this case. You
really only need one method corresponding to addTask()/addSubTask().
> For "<foo>":
>
> - first try createFoo()
> - if no such method is found, try to create a foo object ( based on
> existing taskdefs )
> - try addFoo( foo )
> - if no such method try addBar() where Bar is an interface implemented by
> foo ( or superclass).
Why not just use addTask( foo )? You're making this more complex than it
needs to be.
Given there is only one method needed, why do you prefer reflection over an
interface?
I originially implemented this using reflection to check for the method.
The interface solution is much cleaner. It adds compile-time type
checking. It also makes the code self-documenting. (You know instantly
which tasks can handle sub-tasks because they implement TaskContainer. You
don't have to search for methods with a particular pattern.)
> Each "try" is just a getMethod() and check if not null, and it's very
> easy. I think the pattern makes sense and in tomcat seems to work fine
> ( addServerConnector() with AjpConnector, HttpConnector, etc ).
Why didn't you use this for Targets?
As I said, I think I just wasn't clear enough about what the patch did.
Hopefully I was clearer in this email.
\x/ill :-}
Re: Subtasks within tasks
Posted by co...@eng.sun.com.
I have few problems with that particular solution:
- it is specific to Tasks ( createSubTask, SubTaskable, etc ) - everything
else in ant is using introspection and patterns.
- it sound a bit to complex
- What is a sub task anyway ? I can't figure what it will do. SubCopy?
If you have a particular task that needs this kind of sub-task we should
try to find a pattern-based solution.
In particular addXXX works fine in this case and doesn't require any
interface ( and it's implemented in tomcat ):
For "<foo>":
- first try createFoo()
- if no such method is found, try to create a foo object ( based on
existing taskdefs )
- try addFoo( foo )
- if no such method try addBar() where Bar is an interface implemented by
foo ( or superclass).
Each "try" is just a getMethod() and check if not null, and it's very
easy. I think the pattern makes sense and in tomcat seems to work fine
( addServerConnector() with AjpConnector, HttpConnector, etc ).
Costin
> The current ANT allows you to have properties within tasks, and these can
> be arbitrarily nested, but each one requires a createXxxx() method to
> return an object that goes along with that XML property. This means you
> can't have general sub-Tasks. You'd have to make a createXxxx() method for
> each task - not feasable.
>
> So, I've implemented some changes that allow arbirary sub-Tasks. There
> is a new interface: SubTaskable which has an addSubTask(Task) method. When
> a property is encountered for which there is no createXxxx() method, the
> element is checked to see if it implements SubTaskable. If it does then a
> task with the appropriate name is created and added using the
> addSubTask(Task) method.
>
> To keep things clean I also modified Target and Task slightly. Target
> now implements SubTaskable. The Task.setTarget(Target) has been changed to
> Task.setTarget(SubTaskable). I also deprecated the Target.addTask(Task)
> method. It does the same thing as the new addSubTask(Task) method. I
> didn't use addTask(Task) in the SubTaskable interface because that might
> conflict with an attribute. With it's two capitals, addSubTask() cannot.
>
> I've attached diffs for ProjectHelper.java, Task.java and Target.java.
> I've attached the complete SubTaskable.java. I've also attached a task,
> SubTaskTest.java, that simply executes each of its subtasks in order.
>
> later,
>
> \x/ill :-}
>
Re: Subtasks within tasks
Posted by William Uther <wi...@cs.cmu.edu>.
OOPS,
I just noticed that I left an old name in as the @author of the simple
SubTaskTest.java Task. I also noticed that my email client is wrapping the
text in attachments. I don't know how to turn that off. I could wrap the
diffs in uucode if that would help?
later,
\x/ill :-}