ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Haas" <thomas.h...@softwired-inc.com>
Subject Re: Ant Principles
Date Tue, 18 Apr 2000 21:38:31 GMT


> Ok, so if we are going to tighten up Ant to get to the point where it
should
> go, we should start off with a set of principles (or goals, or design
> criteria, or whatever you want to call them) that we all agree on. It's

Good idea - good work!


>   Extensibility:
>
>   Ant must provide an easy to use extensibility path. Extensions
>   must be easy to write for the programmer and easy to place where they
>   can best be used.
>
> Conceptual Overview (here's a bit more detail, but still should be
> relatively agreeable)
>
>   The base unit of work is a Project. A Project is defined by an
>   XML text file and as an object of type Project at runtime.
>   A Project is a collection of Property definitions and Targets.
>
>   Properties:
>
>   Properties are mutable name-value pairs that are scoped to the
>   Project and held in a List. The property list can be modified at
>   runtime allowing properties to be added, removed, or changed. The
>   property list is loaded from the XML based project file. It is useful
>   to be able to override the properties contained in a project file and
>   so optional parameters to the ant runtime can be defined to do so:
>
>   ant projectfile.xml -props foo=bar;baz=bop [target]

As others pointed out, single declaration of properties is also preferred on
my part. In addition to other proposal, properties could be specified like
the system properties, maybe using a different option:

ant projectfile.xml -Pfoo=bar -Pbaz=bop [target]

"P" for property. "D" may confuse with system properties.


>   The other part that needs work is what happens inside the taskimpl
>   areas. Right now reflection is used to set attributes on bean methods
>   but it's heniously unclear how the best way to reflect the rest
>   of the elements within the taskimpl tag should be performed. For

Reflection and beanstyle configuration are great. From the experiences with
the JUnit task, separating the object being configured and the
implementation of the functionality eases reuse. For example to be able to
reuse the functionality implemented by MathcingTask, it must be subclassed.
Reusing MatchingTask and Exec causes a problem, as there is no multiple
inheritance in Java.

Therefor at least the core components should be build in a reusable way or
the object model Project<-1--*-Task may be extended  to
Project<-1--*-Task-1---*>Task (UML in simple ASCII is not easy - I hope you
get the idea).


> Installation:
>
>   Far far far too many people are inluding ant.jar with thier
>   software. Do people include make? No. Do people include diff?
>   No. So, we need to get Ant to the point where it's a first
>   class citizen on the user's machine. This means an install
>   and it means a directory structure.
>
>   I'm proposing this:
>
>     $install_dir/bin/ant.sh
>                     /ant.bat
>                 /lib/ant.jar
>                 /ext
>                 /opt/tasktype1
>                     /tasktype2/tasktype2.xml
>                               /src/...

We already preinstall ANT on all our dev machines. I would like to have a
built time option to include optional stuff into the ant which gets
installed. I do not think this is an issue, I simply would like
extensibility not only at run time using some sophisticated installation
procedure, but also at build time.


>   All tasks must be written to accept a common representation of
>   filenames that can be translated at runtime to a File object that is
>   valid for the runtime operating system. This common representation can
>   be translated into a File object by a convience method on the Project
>   object.

YES for common internal representation. As others pointed out, a common
external representation is too much.
I would even suggest to use the URL object as representation of resources.
For extensibility objects manipulation file content should offer a stream
based interface, to allow integration of resources provided by FTP or HTTP
servers or database (YES, we are working on this).
Offering file operation in an object outside Project, would ease reuse.


- tom



Mime
View raw message