----- Original Message ----- From: "Diane Holt" <[EMAIL PROTECTED]> To: "Ant Users List" <[EMAIL PROTECTED]> Sent: Thursday, May 30, 2002 2:53 PM Subject: RE: Setting Enviroment alias in properties file - CLARIFICATION
> --- "White, Joshua A (AG, COMM)" <[EMAIL PROTECTED]> wrote: > > It's just redundant. > > True. > > > If anyone has any suggestions, let me know. > > The only one I could think of that didn't incur yet more redundancy was to > add a command-line flag to Ant -- so that's what I did. Now, whether it'd > be acceptable to the rest of the committers is the next question at hand. > I don't see anything wrong with it, and since most people nowadays do take > advantage of the advent of <property environment.../>, it seems reasonable > to add it as a command-line option -- much like the new -propertyfile > option (and if you always wanted it to happen, which you likely would, you > could set it in ANT_ARGS, so you wouldn't have to actually type it in the > command line everytime). But maybe there are implications to doing it as a > command-line arg that I don't see. My view is that importing properties is a symptom of a larger problem: sharing information between files. Adding more command line opts doesnt address the more fundamental issue that we need better ways of importing build files into build files I do use <property env> in most of my build files, but I always read it in after reading the user, project and masterbuild property files, in that order. This gives me 3 places to override an env variable, if I so choose. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
