ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject RE: Properties and the <ant> tag
Date Sun, 10 Jun 2001 14:26:39 GMT
> From: Peter Vogel [mailto:pvogel@arsin.com]
>
>
> > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> >
> >
> > 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.
>
> What does "upperfoo" represent?  A string?, the name of a variable?
> something else?  That's why I didn't like it, it's not explicit about
> what it is doing...
>

Well, it is the name of a property. If we were to have task-level
"if/unless", kind of what your first proposal required, it is a shorthand
for:

  <property name="foo" value="${upperfoo}" if="upperfoo" />

but I guess I donot what to get into the if/unless can of worms again.

> >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?).
>
> Despise is right, "spector" is what you mean :-)   I agree that,
> in general, invisibly mutable properties are a bad idea, there
> have been some interesting build debugging sessions where a
> deeply hidden makefile overrode something it shouldn't have (which
> is why the developer hid it :-)  So I'll reverse my opinion of
> what the default value of "override" should be, but I won't reverse my
> opinion that this syntax is more "transparent" than the one
> you propose.
> I can, for example, detect all overrides in a tree with a single
> find . -name build.xml -exec grep -l 'override="true"' {} \;
> command, in
> your suggestion, I cannot do that...
>

I see your concern, but the whole point of changing the rules is to make
sure that the properties in the local build file take precedence. Let me
give you the following example:

	<property name="a" value="A" />
	<property name="ab" value="${a}/B" />

now in some target, I do:

	<antcall target="doit" >
	  <param name="a" value="C" />
	</antcall>

during the execution of the <antcall> I think you would agree that the only
reasonable value for ${ab} is "C/B" , which is what you get from executing
the command

	ant -Da=C doit

Otherwise you have an inconsistent set of property definitions. For that to
happen, you would need to specify override="true" everywhere a property
value uses some other property, which would make the whole thing rather
meaningless.


Jose Alberto

> > > > -----Original Message-----
> > > > From: Diane Holt [mailto:holtdl@yahoo.com]
> > > > Sent: Thursday, May 24, 2001 2:40 PM
> > > > To: ant-dev@jakarta.apache.org
> > > > Subject: RE: Properties and the <ant> tag
> > > >
> > > >
> > > > --- Jose Alberto Fernandez <j_a_fernandez@yahoo.com> 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
> > > >
> > > > =====
> > > > (holtdl@yahoo.com)
> > > >
> > > >
> > > >
> > > > __________________________________________________
> > > > Do You Yahoo!?
> > > > Yahoo! Auctions - buy the things you want at great prices
> > > > http://auctions.yahoo.com/
> > > >
> > >
> >
>


Mime
View raw message