ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jay Glanville" <>
Subject RE: [PATCH] refactoring of javac task into factory
Date Sat, 16 Dec 2000 03:37:14 GMT

> -----Original Message-----
> From: Peter Donald []
> Sent: Friday, December 15, 2000 9:43 PM
> To:
> Cc: Ant-Dev (text)
> Subject: RE: [PATCH] refactoring of javac task into factory
> At 09:28  15/12/00 -0500, Jay Glanville wrote:
> >> I am not sure I like it ... as a
> >> matter of fact I don't like it. 
> >> It will now encourage users to create
> >> incompatable build files by hardwiring compilers into the the 
> >> build file ;(
> >
> >I'm not sure I understand your concern.  It was my 
> impression that we wanted
> >to get away from "magic properties" (the build.compiler is 
> an example of
> >one).  It's relatively easy to go through the ant-dev 
> archives looking for
> >"magic properties" to find people saying they want to reduce 
> their usage.
> >The only way that I thought that we could get rid of them is 
> to replace them
> >with explicit attributes of a task.
> yep - thats one way ;)
> >On the subject of the "creation of incompatable build files 
> by hardwiring
> >compilers into the build file", let me show you how this new 
> attribute
> >PREVENTS that!  Lets look at the following build.xml snippet:
> >   <property file="" />
> >   <property name="prop.compiler" value="modern" />
> >   <javac compiler="${prop.compiler}" .../>
> It relies on people being intelligent about it. I prefer to 
> think of people
> as stupid/lazy and then protect them selves from themselves 
> ;). Now lets
> consider the case where Joe Sixpack doesn't enable this and 
> hardwires it to
> "modern".
> I come along and definetly want to use jikes - what choice do I have -
> either modify the build file (yuck) or live with "modern" 
> (double yuck) ;).
> Now compare this to the current situation. Usually most 
> projects include at
> the top something like
>   <!--
>     Give user a chance to override without editing this file
>     (and without typing -D each time he compiles it)
>   -->
>   <property file=""/>
>   <property file="${user.home}/"/>
> in which case I just drop a property file in relevent place to change
> compiler. I have global properties set to use jikes so I am 
> sweet and I am
> good to go already.
> Alternatively if they don't embed above snippet I can do a
> -Dbuild.compiler=jikes on commandline. Another option that is no go if
> compiler is specified as attribute.
> >What does this mean?  Without any property over-rides, then 
> the modern
> >compiler is used.  If the "prop.compiler" property is 
> over-ridden, (with
> >"jikes" for example) then the jikes compiler is used ... all 
> without the
> >usage of magic properties!
> naah it uses magic properties - just not implicit ones. Worse 
> it means that
> some projects may or may not provide the magic properties or 
> may name them
> different things ;(

;-) I think we have a difference of opinion as to the definition of a magic
property. ;-)  To me, a property is magic if it is implicit.  A property is
magic if the task using it doesn't get the information from it's attribute
values.  In my patch, the task does not have to rely on the existence of a
"global variable" (ie: a system property), it gets all it's information from
it's attributes.

> >The ability to provide a classname for the
> >compiler allows much more flexibility for users where the 
> core supplied
> >tasks don't meet their needs.
> right - but I think we can do it better someother way ;)


I feel another philosophical state comming on again ...

To me, a magic property is analogous to a global variable in C.  If you
designed your code right, there were very few needs for global variables.
To me, attributes in ant are analogous to parameters in a method, where the
task is the method.  If I can, I'd like to remove global variables.

Thank you to all who withstood my philosophical state without rolling their
eyes ... I appreciate that. ;-)


View raw message