ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <jofer...@us.oracle.com>
Subject Re: Controversial <foreach> task
Date Mon, 28 Feb 2000 21:18:05 GMT


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


Mime
View raw message