ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sam Ruby" <>
Subject Re: Property substitutions, Contributed Tasks, & New features
Date Fri, 12 Jan 2001 12:58:22 GMT
Conor MacNeill wrote:

> As the build runner I want priority over the build writer.


> The build.compiler flag would be a good example, but even
> build specific properties should be controllable from the
> command line. To have to edit the build file to change
> one of those values would be a chore.

I realize that this is not the same issue, but the build.compiler flag has
always irked me.  I described my issue before, but it never got any
traction.  But I will describe it again just in case the time for such
ideas is better now.

One think I very much like about ant is it's near zero learning curve.  I
just got another convert yesterday, and it always is a joy to behold.  What
helps make this possible is the fact that there is almost no hidden
knowledge about how things work inside required to get started.  Much of
the original implicitness, like the "init" task and the automatic copying
of non-java files into the target by javac have long since been removed.

The build.compiler is an exception. It "talks" directly to the inner
workings of a specific task, without much in the name giving a visual clue
as to how it works.  For example: does it apply to the rmic task?  No.

For starters, I would prefer a compiler attribute to the javac task.

Then I would go a step further, and make it default to the value of
${javac.compiler}, if present.  For now, we could have property
javac.compiler default to the value of build.compiler, and deprecate it.

Taking this a step further, I would make any task's attribute default to
${<task>.<attribute>}.  Now I can control deprecation on compiles, the
window title on javadoc, the useTimestamp option on get, the jvmarg on
java, ... all from the command line!

Perhaps not something to do on a 1.x, but on a 2.0?

- Sam Ruby

P.S.      Yes, I am the creator of the build.sysclasspath property.  So,
sue me.  ;-)
     [I would have prefered to name it project.sysclasspath]

View raw message