ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Properties and the <ant> tag
Date Sat, 26 May 2001 12:33:54 GMT
Sorry it took me so long to answer this one.

> From: Diane Holt []
> --- Jose Alberto Fernandez <> wrote:
> > 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?

This is a good issue to try to tackle.

ANT by itself does  not know anything about you deciding to call your
property ${debug}, and if you were to incorporate building some other
people's project as part of your main build, you may have the case that for
them ${debug} could mean "set the product's debug mode" instead of asking
javac to compile with the debug flag.

So any real solution, cannot just pass things blindly, it needs to
understand what is going on. So, with that in mind, here is my take on it:

Solution one, pass things arround:

You know the few parameters that you want to be able to take effect across
subprojects and you pass them around.

	<ant ......>
	  <param name="debug" value="${debug}" />
	  <param ..... />

this to me is the most correct way of doing it. It is precise and clear.
Yes, it means you need to know what you want to pass arround when you write
your buildfile. But hey, you also need to write your buildfile with the
targets you want people to have. In other words you need to design what
features you want in your build.

A second option is to be more clear in what we mean by "default value" in
your build as well as in ANT. I am not proposing that properties from
calling builds are not visible. But what I am asking is for their values not
to take precedence (unless it came in as a <param>).

What that means, is that properties inherited (not <param>) form calling
builds are like "defaults" their value apply unless you set one locally.
Since most properties are defined locally, they do not care what was passed.
On the other hand, you can check if any value was inherited for things that
you want a default to apply.

	<target name="defaultDebug" unless="debug" >
	  <property name="debug" value="false"/>

now this can be kind of cumbersome, a nicer way would be to be able to tell
<property> to allow for default values. Adding something like:

	<property name="A" value="aaa" default="B" />

which means assign to property "A" the value "aaa", unless the property "B"
is set, in which case assign that value. With this, you could define yout
${debug} as:

	<property name="debug" value="false" default="debug" />

I do not like this style that much because the sub-project is assuming that
any calling project is using properties with the same meaning as it is used
locally. Which is not "low-coupling" at all. And I think, low-coupling in
build processes are as good as they are in anything else. But it is better
than what we have today.

> (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.)

Oh, I agree with you that templates would be good. I am not sure I would use
them for defining global properties but I would use them to reduce the
amount of code I need to write. Even something as simple as the following
would be of great help and not require learning some new template lenguage
or anything:

	<tasktemplate name="subproject" params="target,dir" >
		<ant dir="${dir}" target="${target}" >
		  <param name="debug" value="${debug}" />

which defines a new task like, named "subproject" with attributes "target"
and "dir" that can be used to pass parameters into the template. So in your
build, you would say something like:

	<subproject dir="parser" target="compile" />

This can shortten your builds and make them more clear. I am not sure how to
acomplish it, but it almost looks like it is feasible in 1.x. And it is not
violating anyones rules, I do not think. Well.... maybe you would have to

	<usetemplate name="subproject" dir="parser" target="compile />

which is not as nice, but preatty good still.

Jose Alberto

View raw message