ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gus Heck <>
Subject Re: Request: Change <javac> debug default to "on"
Date Thu, 07 Nov 2002 16:22:44 GMT
Actually, I like your idea Dominique, but I would greatly prefer that 
there is no way for the XPath information to get sprinkled into random 
locations in the build file. XPath is something I need to learn more 
about, so maybe that is a silly concern, but one of the key issues for 
me and build files is that information be organized in a reasonable 
fasion. (hence my previous arguements about placement of top level 
tasks, which unfortunately didn't seem to get adopted)

In Ant files as in any form of communication, standardized structure and 
components make it easier to convey information to others who also 
understand the structure and know the components. (Including yourself 6 
months later, assuming you havn't forgotten the language :) ).


Dominique Devienne wrote:
> I think I agree with what you are saying, just not on the solution proposed.
> I don't like the magic properties either. But as I've said before, this kind
> of things could be handle more generically, and more expressively (IMHO,
> which Costin seemed to disagree with last time I exposed this) using a
> generic mechanism to assign attribute values in Ant which is similar to the
> Xdefault way of assigning resources, but uses an XPath syntax.
> Just consider the XPath view of all your build files, and simply select all
> the attributes you want to assign with the right XPath query. E.g.
> //javac/@debug = true
> This could also replace (supercede) the build.compiler property to say for
> example
> //javac/compiler = jikes
> As I said before, not having such a mechanism forces to use too many
> properties with defaults, just so it's override able. Having this generic
> way to override things would be very powerful (and based on an XML standard
> like XPath too!).
> It would also allow changing the defaults of any task attribute that is not
> appropriate for the site, and build file writers.
> I don't really know the right place to issue such overrides, but maybe it
> should be another XML files constituting the *environment* of Ant, like
> global attribute definition override (like described above), logger and/or
> listeners to use, taskdefs/typedefs common to many build files, etc...
> Such a global config file to Ant could also define additional site-specific
> default exclude patterns (instead of having to hard-code them in Ant), and
> generally tune the global policies used internally by Ant...
> It seems to me sometimes I'm the only one who thinks such thoughts, and that
> doesn't end to surprise me ;-) I guess I must be special... Please no
> comments on how special ;-) --DD
> -----Original Message-----
> From: Jose Alberto Fernandez [] 
> Sent: Thursday, November 07, 2002 8:05 AM
> To: Ant Developers List
> Subject: RE: Request: Change <javac> debug default to "on"
>>From: Gus Heck []
>>Did he say magic property? uh oh...
>>(Mail shield up)
>>Magic properties have been fairly unpopular. They generally obfuscate 
>>behavior, and clutter up the namespace available for 
>>properties. In this 
>>case it would put critical information (critical for some at least) 
>>about what javac is really doing in an obscure location away from the 
>>invocation of the javac task.
> Do you think that build files would be easier to write or more flexible if
> we had to specify which compiler to use on each individual <javac> task?
> I would think that it is very rare the case in which you want some files
> compiled by
> one compiler and other files with a different compiler. Moreover, different
> people on the same project may want to use different compilers.
> "Magic properties" in reality are no other thing than global-predefined user
> preferences;
> and it makes a lot of sense for this kind of usage.
>>Besides this I am not sure why setting a property would be 
>>better than 
>>setting the flag in javac. The point under discussion is should the 
>>_default_behavior_ change. There isn't really any need for a 
>>new way to 
>>customize the behavior of javac globally is there?
> Well a very important point of the discussion is the alleged cost of
> changing
> all those build files if we change this default behavior. The only thing I
> am proposing
> is a way to define this default behaviour as a preference of the user (or
> developement environment).
> Just the same as the compiler preference does.
> Jose Alberto
> --
> To unsubscribe, e-mail:   <>
> For additional commands, e-mail: <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message