Controversial task

[ru...@us.ibm.com]

It is easy to deamonize the proposed <foreach> task.  But one peek at
Ludovic Claude's implementation of this task shows that this need not add
any complexity to the implementation.  So, instead of letting this
discussion die down, I'd like to suggest it continue in two directions.

1) Requirements.  What are the types of problems that people need to solve
that can't be easily accomplished with the current Ant?  Most of my
experience with foreach like structures in make are to handle things like
directory recursion.  Thankfully due to Arnout Kuiper's pattern matching
and the definition of tasks like javac, this is not necessary with Ant.
Can somebody give concrete examples of problems that are hard to solve with
the existing Ant?

2) Enablement.  Users are able to provide their own task definitions, and
this should be encouraged.  So even if we deem <foreach> to be something
that we do not want in the core, are there changes that we could make which
will allow others to create the functionality that they need?  Ludovic's
implementation requires properties to be variables as opposed to simple
constants as they are now.  Will Uther has suggested an addText method.
Both seem to be reasonable changes to me.

- Sam Ruby

Re: extension mechanism

[William Uther <wi...@cs.cmu.edu>]

>> Actually, one of the things I'd quite like to have is a project specific
>> classpath.  I agree that there is logic that should go in it's own task.

>> We could have a simple classloader that reads in the extra task
> definitons.
>> 
>> <taskdef name="deathDestroyerOfWorlds"
>> classname="abandon.all.hope.ye.who.enter.here" classpath="${taskdefs}" />
> 
> Eh? You were talking about a project specific classpath, but your
> illustration is of a taskdef. I'm not following.

I was referring to a classpath from which project specific tasks get
loaded.  I think a classpath for things like javac can already by handled
with a property.

Sorry for not being clearer.  (Not sure I should be let anywhere near a
programming language - I can't get English right. :)

\x/ill         :-}

Re: extension mechanism

[James Duncan Davidson <ja...@eng.sun.com>]

> Actually, one of the things I'd quite like to have is a project specific
> classpath.  I agree that there is logic that should go in it's own task.
(I
> use the Ozone Database <http://www.ozone-db.org/>, which has its own rmic
> type tool that it would be nice to make into a task.)  However, this is
> really a project specific task.  I don't want it in my normal ANT
classpath
> or in my system classpath.
>
> We could have a simple classloader that reads in the extra task
definitons.
>
> <taskdef name="deathDestroyerOfWorlds"
> classname="abandon.all.hope.ye.who.enter.here" classpath="${taskdefs}" />

Eh? You were talking about a project specific classpath, but your
illustration is of a taskdef. I'm not following.

At first glance a project level classpath isn't a bad idea. I'm not sure how
to best reflect that into tasks, or if the tasks should just ask the project
if there is a specific classpath to be used. Of course, there's the issues
of whether the given classpath is additive or replaces the current
classpath. So far the behavior in the javac task has been additive.

.duncan

Re: extension mechanism

[William Uther <wi...@cs.cmu.edu>]

> = Duncan
>> = Ludovic

>> Can we consider some kind of extension mecanism to ant? I find that
>> having
> to
>> define <taskdef>
>> in each project is a pain (especially is you have >10 projects...). I've
> seen
>> that you can read default
>> properties from your home directory, why not have that also for default
>> taskdefs?
> 
> That's not a bad idea as well. Having a $HOME/.antrc or some such would
> not be a bad thing imho.

Actually, one of the things I'd quite like to have is a project specific
classpath.  I agree that there is logic that should go in it's own task. (I
use the Ozone Database <http://www.ozone-db.org/>, which has its own rmic
type tool that it would be nice to make into a task.)  However, this is
really a project specific task.  I don't want it in my normal ANT classpath
or in my system classpath.

We could have a simple classloader that reads in the extra task definitons.

<taskdef name="deathDestroyerOfWorlds"
classname="abandon.all.hope.ye.who.enter.here" classpath="${taskdefs}" />

later,

\x/ill          :-}

Re: Controversial task

[James Duncan Davidson <ja...@eng.sun.com>]

> > > Ok, so far I've just proved that foreach *might* be useful in sporadic
> > > situations but the need for
> > > it reflects more other problems in the existing tasks.
> >
> > I don't think that you've proved that control structures are necessary.
I
> > think that you've proved that there are task types that can be
introduced
> > that make life easier for the XML writer and which do more of the logic.
>
> I disagree - it will make the life easier for ant-programmers and allow
> more logic. For XML writer ( or a GUI tool that will build the xml ) the
> life will be _very_ hard, instead of a simple tool they will have a
> programming language.

I think that we are in agreement and not in disagreement here. I was trying
to say that he's proved that more capable tasks need to be written that do
the logic. I wasn't saying anything about logic in the build.xml files.

.duncan

Re: Controversial task

[co...@eng.sun.com]

> > Ok, so far I've just proved that foreach *might* be useful in sporadic
> > situations but the need for
> > it reflects more other problems in the existing tasks.
> 
> I don't think that you've proved that control structures are necessary. I
> think that you've proved that there are task types that can be introduced
> that make life easier for the XML writer and which do more of the logic.

I disagree - it will make the life easier for ant-programmers and allow 
more logic. For XML writer ( or a GUI tool that will build the xml ) the
life will be _very_ hard, instead of a simple tool they will have a
programming language. 

Costin

Re: Controversial task

[James Duncan Davidson <ja...@eng.sun.com>]

> - lots of rmic: for that one i had to write a generator of tags that takes
the
> list of implementation
> class and generates the <rmic> tags to build the stubs for them. A for
loop is
> an easy solution,
> but we might as well extand the functionallity of rmic so that it can
discover
> the remote classes
> in a folder and generate the stubs for them

This solution of an rmicdir task (or some such name) that would reflect into
all classes and find the remote classes would be a decent thing to do.

> Ok, so far I've just proved that foreach *might* be useful in sporadic
> situations but the need for
> it reflects more other problems in the existing tasks.

I don't think that you've proved that control structures are necessary. I
think that you've proved that there are task types that can be introduced
that make life easier for the XML writer and which do more of the logic.

> (it would be nice also to have a serialver task)

Sure. Write one up. :)

> Can we consider some kind of extension mecanism to ant? I find that having
to
> define <taskdef>
> in each project is a pain (especially is you have >10 projects...). I've
seen
> that you can read default
> properties from your home directory, why not have that also for default
> taskdefs?

That's not a bad idea as well. Having a $HOME/.antrc or some such would not
be a bad thing imho.

.duncan

Re: Controversial task

[Jose Alberto Fernandez <jo...@us.oracle.com>]

costin@eng.sun.com wrote:

> Right now ant is a collection of Tasks and a small driver that calls the
> tasks. The Tasks are independent java beans, with no constraints ( it is
> not even necesary to extend Task - see the Test task defined in Tomcat )
>

As I said in a previous message, how declarative can the build files be if we
keep on adding more and more obscure functionality to the tasks?
How can anyone understand what the tasks are doing without needing
to go read the java classes? I love the extensibility that one gets from
taskdefs, don't get me wrong.

>
> It is possible to use the tasks from a different framework (
> call them from a Java program as normal beans, with no XML involved). Xml
> is just a way to store the sequence of tasks and init ant.
>
> > > 1) Requirements.  What are the types of problems that people need to solve..
> >
> > - lots of rmic: for that one i had to write a generator of tags that takes the
> > list of implementation
> > class and generates the <rmic> tags to build the stubs for them. A for loop is
> > an easy solution,
> > but we might as well extand the functionallity of rmic so that it can discover
> > the remote classes
> > in a folder and generate the stubs for them
>
> Write a new/change rmic to take a "files" property with all the files you
> need.
>

So how many versions of rmic do we want to have floating arround?
When do we stop embelishing a tast yout to solve our little corner problem?

>
> > Ok, so far I've just proved that foreach *might* be useful in sporadic
> > situations but the need for
> > it reflects more other problems in the existing tasks.
>
> Everything "might" be usefull, the problem is what is the cost ? We
> should not implement  every feature that "might" be usefull (
> paperclips?).
>
> In this particular case it's even worse - it changes a fundamental design
> choice, and will disable other usefull features.

Which features do we loose with those changes? Can you give us some example,
maybe we do not understand the ramifications of the change.

>
>
> > >
> > > 2) Enablement.  Users are able to provide their own task definitions, and...
> >
> > Can we consider some kind of extension mecanism to ant? I find that having to
> > define <taskdef>
>
> We have one - it's called java.
>
> IF you find <taskdef> a pain, define/change taskdef to read a list of
> properties from your own location ( ~/.ant.taskdefs ).
>
> > in each project is a pain (especially is you have >10 projects...). I've seen
> > that you can read default
> > properties from your home directory, why not have that also for default
> > taskdefs?
>
> Why not changing a Java file and adding the loop you need instead of
> transforming ant into a programming language just to make that loop ?
>
> Costin
>

--
  ------------------------------------------------------------------------
 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: Controversial task

[co...@eng.sun.com]

Right now ant is a collection of Tasks and a small driver that calls the
tasks. The Tasks are independent java beans, with no constraints ( it is
not even necesary to extend Task - see the Test task defined in Tomcat ) 

It is possible to use the tasks from a different framework ( 
call them from a Java program as normal beans, with no XML involved). Xml
is just a way to store the sequence of tasks and init ant. 



> > 1) Requirements.  What are the types of problems that people need to solve..
> 
> - lots of rmic: for that one i had to write a generator of tags that takes the
> list of implementation
> class and generates the <rmic> tags to build the stubs for them. A for loop is
> an easy solution,
> but we might as well extand the functionallity of rmic so that it can discover
> the remote classes
> in a folder and generate the stubs for them

Write a new/change rmic to take a "files" property with all the files you
need. 

> Ok, so far I've just proved that foreach *might* be useful in sporadic
> situations but the need for
> it reflects more other problems in the existing tasks.

Everything "might" be usefull, the problem is what is the cost ? We
should not implement  every feature that "might" be usefull (
paperclips?). 

In this particular case it's even worse - it changes a fundamental design
choice, and will disable other usefull features. 

> >
> > 2) Enablement.  Users are able to provide their own task definitions, and...
> 
> Can we consider some kind of extension mecanism to ant? I find that having to
> define <taskdef>

We have one - it's called java.

IF you find <taskdef> a pain, define/change taskdef to read a list of
properties from your own location ( ~/.ant.taskdefs ).


> in each project is a pain (especially is you have >10 projects...). I've seen
> that you can read default
> properties from your home directory, why not have that also for default
> taskdefs?

Why not changing a Java file and adding the loop you need instead of
transforming ant into a programming language just to make that loop ?

Costin
 

Re: Controversial task

[Ludovic Claude <lc...@websitewatchers.com>]

rubys@us.ibm.com wrote:

> 1) Requirements.  What are the types of problems that people need to solve..

I gave a look at the problems i see in my build files, and this is what i have:

- lots of keysubst tasks, in fact they could -and should- be removed by using
the new filter
ability of copydir. The only issue here is that i need to be able to define
locally my filters.
- lots of rmic: for that one i had to write a generator of tags that takes the
list of implementation
class and generates the <rmic> tags to build the stubs for them. A for loop is
an easy solution,
but we might as well extand the functionallity of rmic so that it can discover
the remote classes
in a folder and generate the stubs for them

Ok, so far I've just proved that foreach *might* be useful in sporadic
situations but the need for
it reflects more other problems in the existing tasks.

(it would be nice also to have a serialver task)

>
> 2) Enablement.  Users are able to provide their own task definitions, and...

Can we consider some kind of extension mecanism to ant? I find that having to
define <taskdef>
in each project is a pain (especially is you have >10 projects...). I've seen
that you can read default
properties from your home directory, why not have that also for default
taskdefs?

Ludovic.