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 :) ).
Gus
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 [mailto:[EMAIL PROTECTED] Sent: Thursday, November 07, 2002 8:05 AM
To: Ant Developers List
Subject: RE: Request: Change <javac> debug default to "on"
From: Gus Heck [mailto:[EMAIL PROTECTED]
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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
