From ant-user-return-16955-qmlist-jakarta-archive-ant-user=jakarta.apache.org@jakarta.apache.org Mon Feb 04 13:56:45 2002 Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 45457 invoked from network); 4 Feb 2002 13:56:45 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 4 Feb 2002 13:56:45 -0000 Received: (qmail 25056 invoked by uid 97); 4 Feb 2002 13:56:35 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 25040 invoked by uid 97); 4 Feb 2002 13:56:34 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 25029 invoked from network); 4 Feb 2002 13:56:34 -0000 Subject: Re: Thoughts about properties To: "Ant Users List" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: David.Bailey@lawson.com Date: Mon, 4 Feb 2002 07:54:28 -0600 X-MIMETrack: Serialize by Router on SMTP/Lawson(Release 5.0.8 |June 18, 2001) at 02/04/2002 07:56:08 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N As for (1), it seems to me that using an entity reference include doesn't buy that much. Won't I still have to put a string (like '&properties') in every build file? Won't ANT still parse the .properties file once for every build file it encounters, and tell me 'Override ignored for property . . . .". for all but the first build file? Maybe I misunderstand what you're saying (I don't know that much about how XML works). As for a concrete use case, let me explain what I'm doing. I've modified the default ant wrapper extensively to suit our needs. In particular, it defines a number of -D= pairs. Other Java projects in the company have cribbed my work (this is the essence of software development). The problem is that these other projects need to define the properties differently. They could copy my script and change the values in the -D= pairs, but this would mean a lot of variations of the ant script floating around in the source tree. Or we could put a big old 'switch' statement in the wrapper, but no one wants that. So it seems the correct solution is to tell each project to maintain its own .properties file. This way, a single ANT wrapper still works for the entire company. But this would be a better solution if it didn't mean that each project must now modify all of its build.xml files (either to add the tag or to add a &properties entity reference). This can easily be done with a script, but it would certainly be slicker if we could simply specify at the command line which .properties file to use and be done with it. Finally, request (2) is simply asking to make properties-handling more flexible. In the same way that different projects need to define their properties differently, different users will WANT to custom-define certain properties. So it would be nice if we could either pass a '-userpref' option to tell ANT to check for a .properties file in ${user.dir}, or by daisy-chaining the .properties files so that ANT could read one .properties files and see that it needs to go read another. The key to dealing with complexity is to add more layers of indirection. --dave "Erik Hatcher" tions.com> cc: Subject: Re: Thoughts about properties 02/01/2002 03:59 AM Please respond to "Ant Users List" This is really a topic for ant-dev, but I'll reply here for now... ----- Original Message ----- From: > I would like to suggest two extensions to ant's use of .properties files > (maybe ant can already do these things, but between reading the doc > and experimenting I didn't see how): > > 1) Add a '-properties ' to specify a properties file > which in effect "globally" for a single ant run. Obviously > it's possible to obtain something close to this functionality > by inserting the tag at the top of my > build file, but if I have my build.xml files set up in a > cascading manner (as I do) and want the flexibility to build > against any build file in any directory, I have to include the > tag in every single build file. And I believe that > ant will reload that same properties file with each build.xml > it parses, which seems like kind of a waste. This particular case could be implemented by doing this: and then: ant -Dcommandline.properties.file= And if that property is not supplied, will not fail, it just ignores it. As for it having to be in every build file... nope. Look at the FAQ and using entity reference includes. > 2) Support cascading .properties files. That is, define some > distinguished string (like 'INCLUDE_PROPERTIES=' > or something) to indicate that once you're done loading the > current properties file, then go out and load the specified one > as > well. I'm not fond of this one - it takes control out of the build files hands and allows properties to be loaded from all over the place. While it seems useful, it doesn't really give you anything that you cannot already accomplish and opens up the door for properties to be overridden in ways that the build file does not desire. The -D provides sufficient power to allow the user to override things already. > I think my reasons for requesting (1) are pretty clear. My reason for > requesting (2) > is simply that my project has some properties which need to be constant > across > a given development environment (so all builds would reference a single, > environment-specific .properties file), and other properties which may > change from > one build to the next, and need to be configurable by the end user (and > thus > driven off a file in ${user.home}). If suggestions (1) and (2) are both > implemented, > then it would be quite easy to slurp up both sets of propeties exactly once > for a > single build, no matter where in my source tree I'm building. All it would > require > (once the .properties files are defined) is a slight modification to the > ant wrapper. Its easy enough to use XML entity references to include a common build piece in all your build files that handles property loading - in the included fragment you'd put 's in whatever order you desire. > Furthermore, the properties defined in the "parent" .properties file could > act as > defaults for properties defined in the "child" .properties file, in case a > certain user > doesn't want to/doesn't know about the user-specific .properties file in > their home > directory. > > Just a suggestion. Interesting, and good, suggestions. Given that these capabilities already exist in some form already, its unlikely that this would be implemented in Ant 1.x. Could you provide a simple concrete use-case for why you'd need this and how the current mechanisms are insufficient to accomplish what you'd want? Erik -- To unsubscribe, e-mail: For additional commands, e-mail: -- To unsubscribe, e-mail: For additional commands, e-mail: