spec/core.html

[Stefan Bodewig <bo...@bost.de>]

ISTR I said I wanted to adapt core/spec.html to what Ant 1.2 already
implemented and where we may have come to another line of thinking in
the meantime.

Well, I started to give it a try, but on the one hand there is not too
much to change and on the other hand some things are not really
decided upon yet, so I back out of this for the moment.

Some notes:

* I'd like to add "being explicit" (couldn't build a noun from it,
sorry, broken english 8-) to the list of goals, this is a special
case of Understandability in some way, but ...

* should we consider "task definitions" part of a project just like
properties? What about the "reference definitions" introduced in
Ant 1.2?

* this document says properties should be mutable. Does this mean
mutable in general (they are right now) or mutable via <property>?

* I'd drop the Note about removing access to the System properties as
well as the one about removing ${} expansion, (1) there doesn't seem
to be a way back and (2) there are still some use cases we couldn't
solve differently.

* Task behave almost like described now. Only difference is that they
get instantiated at parser time (to have something you can reference
to in scripts for example).

* Re task jar layout, well I think we've agreed to use an XML file
inside META-INF instead of MANIFEST entries. This gives us more
freedom (and I'd prefer to allow for multiple tasks to be put into a
single JAR file).

* I'd prefer user preferences and standard properties
(~/ant.properties in this document) to be defined in an XML file using
Ant's own syntax to be consistent, i.e. instead of 

user.taskdir=anttasks/

use

<property name="user.taskdir" value="anttasks/" />

instead of

javac.debug=on
build.compiler=jikes

use

<taskconfig task="javac">
  <default attribute="debug" value="on" />
  <implementation>jikes</implementation>
</taskconfig>

or similar.

* The Configuration of Tasks section is mostly implemented, search
order of tasks is missing form obvious reasons.

* The prop=name syntax to define properties on the command line (as
opposed to -Dprop=name) won't work on Windows because Windows will
pass this as two arguments prop and name to ant.bat (making it
impossible to distinguish between property definitions and targets).

* I think Ant works quite well without an explicit File Name
convention, we seem to have mastered most of the problems without it.

* relative files are resolved relative to the project's basedir
instead of the directory where the build file resides. Seems the more
natural choice.

Stefan