> 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
