> From: Peter Vogel [mailto:[EMAIL PROTECTED] > > Of course, the right answer can be seen in Gnumake, the > variable (property) assignment can be specified to override > external settings or to be explicitly subservient to external > settings. I used it all the time, to set up "default" tool > locations which could then be overridden by a developer's > specific environment. Assuming a developer installed everything > where they were told to in the documentation I provided, it was > possible to build with a *completely* empty environment -- if not, > they had to set a documented environment variable to specify their > location for the tools installed in a non-standard place. > > In ant I'd propose this: > > <property name="foo" value="myfoo" unless="${foo}"/> > > Makes the property setting subservient to upper levels, while: > > <property name="foo" value="myfoo"/> > > Makes the local property setting override the upper level settings. >
I proposed something very similar which I called default value, a slightly modified version of my original post: <property name="foo" default="upperfoo" /> this give the local "foo" the value of "upperfoo" if defined, otherwise it stays undefined. Properties from the caller are visible but do not take precedence, unless specified as a <param> in the call. So your stuff avove is written as: <property name="foo" default="foo" /> <property name="foo" value="myfoo" /> > Alternatively: > > <property name="foo" value="myfoo" override="false"/> > > <property name="foo" value="myfoo" override="true"/> > > Where the default value of the override attribute would, IMHO be > "true". > This one I do not like as much because it looks like the callee can override no matter what, which raises the expecter of mutable properties, that I despise(sp?). Jose Alberto > -Peter > > > -----Original Message----- > > From: Diane Holt [mailto:[EMAIL PROTECTED] > > Sent: Thursday, May 24, 2001 2:40 PM > > To: [EMAIL PROTECTED] > > Subject: RE: Properties and the <ant> tag > > > > > > --- Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: > > > I have mentioned it before. > > > > I think almost everyone has, at some point in time :) And I > > think pretty > > much everyone agrees (to a greater or lesser degree) that > the way it's > > currently being done isn't ideal -- which is why it will be > > changing for > > Ant2. > > > > > The current semantics makes absolute non-sense since it > assumes that > > > every property in every biuldfile being build has the > same meaning. > > > > Granted -- but turn it around the other way: What about > > properties that do > > have the same meaning? For example, attributes whose values > > are given as a > > property. If I define the value for, say, the "debug" > > attribute in <javac> > > with ${debug}, which is set to 'false' by default, and I want > > to define it > > to 'true' for a particular run, I'd want that value to be in > > effect for > > the <javac> tasks in all the sub-projects, not just the > > top-level project. > > How would you see having sub-projects getting that value, if > > they're not > > getting it from the parent project? (I'd like to see > > something like "task > > templates", so you not only don't have to worry about > things like the > > example above, but you also then don't have to replicate the > > entire task > > everywhere you want to use it, and instead you'd just have > that in one > > place, with only those attributes that differ [eg., the > > included/excluded > > files] being specified in the tasks within the targets. But I > > can't really > > propose that, since I'm not yet up-to-speed enough with Java > > to be able to > > write the code for it, and it would be unfair to expect > > someone else to > > just because I'd like to see it work that way.) > > > > Diane > > > > ===== > > ([EMAIL PROTECTED]) > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Auctions - buy the things you want at great prices > > http://auctions.yahoo.com/ > > >
