> -----Original Message----- > From: Peter Donald [mailto:[EMAIL PROTECTED] > Sent: Friday, December 15, 2000 9:43 PM > To: [EMAIL PROTECTED] > 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="designer.overrides.properties" /> > > <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=".ant.properties"/> > <property file="${user.home}/.ant.properties"/> > > 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 ;) Like? 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. ;-) JDGlanville
