You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Mike Douglass <do...@rpi.edu> on 2000/10/26 16:28:30 UTC
local properties
I've just been moving a number of projects into the ant (1.2) world.
My preferred way of working with these projects is to have one build.xml
file with a target for each sub-project with each target executing the
build.xml file within that subprojects directory.
Each build.xml file is relatively simple (most of them are almost
identical) and the main build.xml file is relatively easy to maintain.
However, it does require some care with use of properties. Some form of
local property would help.
Mike Douglass douglm@rpi.edu
Senior Systems Programmer
Server Support Services 518 276 6780(voice) 2809 (fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
Re: local properties
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "MD" == Mike Douglass <do...@rpi.edu> writes:
MD> So I guess that the dir attribute [of <ant> --SB] is really the
MD> basedir property in disguise.
Judging from the code you are right. This is one thing that should be
changed (to make the basedir attribute of the sub project supply the
default value), I've added it to my (private) TODO list.
On the other hand, this is the documented behavior. From the docs
(describing the dir attribute of <ant>):
"the directory to use as a basedir for the new Ant project. Defaults
to the current directory."
Stefan
Re: local properties
Posted by Mike Douglass <do...@rpi.edu>.
At 05:23 PM 10/30/2000 +0100, Stefan Bodewig wrote:
> MD> For example, is it a bug or is it intentional that the basedir
> MD> property always refers to the directory containing the top level
> MD> build file?
>
>I thought basedir would be the one and only exception to the rule that
>parent project's properties are carved into stone. In Ant 1.2
>${basedir} will always expand to the "current" project's basedir, at
>least it does for me.
In my top-level file I had something like
<target name="bld.uslcapp" depends="rpi.sss.usapplet.depends">
<ant antfile="${user.dir}/bld/rpiusage/uslcapp/build.xml"
target="build" />
</target>
The top level build.xml is something like x:\dev\bld\build.xml. I cd to
x:\dev and do
ant -buildfile=bld/build.xml bld.uslcapp
and everywhere basedir is x:\dev\bld. About a dozen targets get executed
all with their own build files and all get the same basedir of "x:\dev\bld"
The debug output shows it being set many times per project.
I reread the <ant ...> description and tried adding the dir attribute, as in
<target name="bld.uslcapp" depends="rpi.sss.usapplet.depends">
<ant antfile="${user.dir}/bld/rpiusage/uslcapp/build.xml"
dir="${user.dir}/bld/rpiusage/uslcapp" target="build" />
</target>
and now I see that basedir for the uslcapp/build.xml is indeed the
directory it resides in. So I guess that the dir attribute is really the
basedir property in disguise. It seems to me that there is no option but to
set the dir attribute for all the sub-projects. Ideally, not setting it
would mean the basedir project was set from the basedir attribute in the
<project ...>
Mike Douglass douglm@rpi.edu
Senior Systems Programmer
Server Support Services 518 276 6780(voice) 2809 (fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
Re: local properties
Posted by James Duncan Davidson <du...@x180.com>.
On 10/30/00 8:23 AM, "Stefan Bodewig" <bo...@bost.de> wrote:
> I thought basedir would be the one and only exception to the rule that
> parent project's properties are carved into stone. In Ant 1.2
> ${basedir} will always expand to the "current" project's basedir, at
> least it does for me.
Yes -- basedir is a concept that is valid for a particular build tree -- and
not in the parent/child build relationship. It's possible that you should be
able to query the runtime from a task to see if the current project is a
child project and then be able to have access to the parents
tree/properties, but that's a separate thought.
.duncan
--
James Duncan Davidson duncan@x180.com
!try; do()
Re: local properties
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "MD" == Mike Douglass <do...@rpi.edu> writes:
MD> I think I remember reading somewhere on the list that the
MD> developer(s) of ant prefer to have one huge build file.
At least one, me, yes. I'm not sure about the rest of the team. This
is a matter of taste and I'm not doing anything to prevent people from
using hierarchical builds, at least I don't intend to do so.
MD> I'd prefer to see continuing support for hierarchical builds.
We've started to discuss the directions we want to take with Ant 1.3
and Ant 2.0 on ant-dev. The way properties propagate from parent build
files to sub projects is one of the issues.
MD> For example, is it a bug or is it intentional that the basedir
MD> property always refers to the directory containing the top level
MD> build file?
I thought basedir would be the one and only exception to the rule that
parent project's properties are carved into stone. In Ant 1.2
${basedir} will always expand to the "current" project's basedir, at
least it does for me.
Stefan
Re: local properties
Posted by Mike Douglass <do...@rpi.edu>.
At 09:06 AM 10/26/2000 -0700, Dino Valente wrote:
>...The way I got around this problem is to have two files: the build.xml
>and buildRules.xml. The buildRules file contains your normal build
>routines. The build.xml file uses the ant task and you set the necessary
>properties there and invoke the subbuild target:
>
> <target name="package" depends="common">
> <ant antfile="buildRules.xml">
> <property name="name" value="MyApp"/>
> <property name="debug" value="on"/>
> </ant>
> </target>
This is getting closer to what I wanted. Essentially the properties defined
within the <ant...> </ant> context are local to that context, that is, they
don't exist outside of it.
Actually, after some experimentation, they truly are local in scope, in
that, if the same name property exists outside of that scope it remains
unchanged. For example
<target name="package" depends="common">
....
<property name="aprop" value="try this"/>
</target>
<target name="package" depends="common">
<echo message="aprop=${aprop}"/>
<ant antfile="buildRules.xml">
<property name="name" value="MyApp"/>
<property name="debug" value="on"/>
<property name="aprop" value="try this changed"/>
</ant>
<echo message="aprop=${aprop}"/>
</target>
with a corresponding echo in buildRules.xml will result in
aprop=try this
aprop=try this changed
aprop=try this
The point of all this is that I want to build an application that has a
number of variants and I want to build them all with one command. The
variants are specified by setting properties as parameters. I was finding
that having set the property once I couldn't change it for the next variant
of the application.
I think I remember reading somewhere on the list that the developer(s) of
ant prefer to have one huge build file. I'd prefer to see continuing
support for hierarchical builds. For example, is it a bug or is it
intentional that the basedir property always refers to the directory
containing the top level build file?
Mike Douglass douglm@rpi.edu
Senior Systems Programmer
Server Support Services 518 276 6780(voice) 2809 (fax)
Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
Re: local properties
Posted by schmitt <re...@gmx.net>.
Thanks a lot
Stefan Bodewig wrote:
> >>>>> "s" == schmitt <re...@gmx.net> writes:
>
> s> Does this mean that when I call build2.xml from build.xml
> s> using the <Ant> task the properties of build2.xml will only exists
> s> during the execution time of the build2.xml file.
>
> Yes. Currently all properties from a parent project (the one using the
> <ant> task) are passed to the sub project (the one being called) but
> no properties get back from the sub project to the master.
>
> Stefan
Re: local properties
Posted by Stefan Bodewig <bo...@bost.de>.
>>>>> "s" == schmitt <re...@gmx.net> writes:
s> Does this mean that when I call build2.xml from build.xml
s> using the <Ant> task the properties of build2.xml will only exists
s> during the execution time of the build2.xml file.
Yes. Currently all properties from a parent project (the one using the
<ant> task) are passed to the sub project (the one being called) but
no properties get back from the sub project to the master.
Stefan
Re: local properties
Posted by schmitt <re...@gmx.net>.
Hello
Does this mean that when I call build2.xml from build.xml using the
<Ant> task
the properties of build2.xml will only exists during the execution time
of the
build2.xml file. I ask this because of I have to build files which uses
mostly
the same properties and I'm searching a method to compile them from a
superxml
file and your example shows nice solution to me.
Yours
Stefan S
Dino Valente wrote:
> I don't know the idea of local properties is being addressed but the Ant
> developers are well aware of this problem (or feature?). The persistence of
> property value is a problem when doing subbuilds as you have described.
>
> The way I got around this problem is to have two files: the build.xml and
> buildRules.xml. The buildRules file contains your normal build routines.
> The build.xml file uses the ant task and you set the necessary properties
> there and invoke the subbuild target:
>
> <target name="package" depends="common">
> <ant antfile="buildRules.xml">
> <property name="name" value="MyApp"/>
> <property name="debug" value="on"/>
> </ant>
> </target>
>
> The property values will override any values in the buildRules file and
> will be persistant for this file only. The biggest disadvantage with this
> approach is that you have to wrap all calls in the main build so it is
> propagated to the subbuild file (e.g clean, javadoc targets...).
>
> Is there a better way?
>
> dino
>
> At 10:28 AM 10/26/00 -0400, you wrote:
> >I've just been moving a number of projects into the ant (1.2) world.
> >
> >My preferred way of working with these projects is to have one build.xml
> >file with a target for each sub-project with each target executing the
> >build.xml file within that subprojects directory.
> >
> >Each build.xml file is relatively simple (most of them are almost
> >identical) and the main build.xml file is relatively easy to maintain.
> >
> >However, it does require some care with use of properties. Some form of
> >local property would help.
> >
> >Mike Douglass douglm@rpi.edu
> >Senior Systems Programmer
> >Server Support Services 518 276 6780(voice) 2809 (fax)
> >Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180
Re: local properties
Posted by Dino Valente <di...@3dstockcharts.com>.
I don't know the idea of local properties is being addressed but the Ant
developers are well aware of this problem (or feature?). The persistence of
property value is a problem when doing subbuilds as you have described.
The way I got around this problem is to have two files: the build.xml and
buildRules.xml. The buildRules file contains your normal build routines.
The build.xml file uses the ant task and you set the necessary properties
there and invoke the subbuild target:
<target name="package" depends="common">
<ant antfile="buildRules.xml">
<property name="name" value="MyApp"/>
<property name="debug" value="on"/>
</ant>
</target>
The property values will override any values in the buildRules file and
will be persistant for this file only. The biggest disadvantage with this
approach is that you have to wrap all calls in the main build so it is
propagated to the subbuild file (e.g clean, javadoc targets...).
Is there a better way?
dino
At 10:28 AM 10/26/00 -0400, you wrote:
>I've just been moving a number of projects into the ant (1.2) world.
>
>My preferred way of working with these projects is to have one build.xml
>file with a target for each sub-project with each target executing the
>build.xml file within that subprojects directory.
>
>Each build.xml file is relatively simple (most of them are almost
>identical) and the main build.xml file is relatively easy to maintain.
>
>However, it does require some care with use of properties. Some form of
>local property would help.
>
>Mike Douglass douglm@rpi.edu
>Senior Systems Programmer
>Server Support Services 518 276 6780(voice) 2809 (fax)
>Rensselaer Polytechnic Institute 110 8th Street, Troy, NY 12180