ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <JFernan...@viquity.com>
Subject RE: spec/core.html
Date Sat, 04 Nov 2000 00:09:38 GMT
Stefan,

taking a quick look at the spec document found certain discrepancies with
the current implementation that I see no reason to change:

1) "defaulttarget" attribute: the attribute in 1.2 is called "default".
   I see no reason to break build files on this issue.

2) mutable properties. I really do not think this is such a good idea,
nor that we need this behaviour in order to do what we need for subprojects

3) If we want the core to be flexible, we need to allow for <taskdef>.

In escence, for me CORE should be <project> <target> <property> <taskdef>.
(including <taskdef library="..." />).
With those constructs, we can define an ant project as just a shortcut
for:
 <project ....>
  <taskdef library="${ant.home}/lib/ant.jar" />

  <target .../>

 </project>

In other words the real basic ANT core is a CORE without any predefined
tasks
except for the two defined above, everything else an be considered user
defined.

Jose Alberto

> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@bost.de]
> Sent: Thursday, November 02, 2000 9:17 AM
> To: ant-dev@jakarta.apache.org
> Subject: spec/core.html
> 
> 
> 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
> 

Mime
View raw message