I agree, you probably don't want to use the ${user.dir} property unless
you want the build.xml in each directory to be able to reference the
directory it lives in.
We put our 'antproject.properties' file in the "root-level" directory (to
use
your terminology), and then define a property called ROOTDIR which
contains the value of this directory. This way, you can define things like
natives.dir=${ROOTDIR}/natives
and it resolves to the same value everywhere. Of course, now ANT has
to pick up the value of ROOTDIR somehow, but it's fairly straightforward
to add '-DROOTDIR=<directory name>' to the ANT wrapper script.
If all of your code and buildfiles are archived, so that users are checking
them out on different machines (which will almost certainly have different
values for ROOTDIR), then you need to do a little more work on the
wrapper script to allow it to set the value of ROOTDIR correctly. But it
can be done: just tell the script to find the directory which contains the
file
'antproject.properties'.
--dave
"Guthrie, John"
<[EMAIL PROTECTED] To: "'Ant Users List'"
<[EMAIL PROTECTED]>
> cc:
Subject: RE: Ant design question(s) -
#1
03/19/2002 10:25
AM
Please respond to
"Ant Users List"
There* is* a problem with using a build.properties at the root level and
having all of the build.xml's reference it. The problem is that some of the
properties piggyback off of ${user.dir} which is different when running ant
in different subdirs. E.g. I have a property:
natives.dir=${user.dir}/natives
where my native source code is. Works for the root-level build.xml, but not
the one in the natives subdir.
And the downside to forcing all ant calls to go through the root build.xml
is that it forces that build.xml to contain *every* target in every subdir
build.xml, which makes it really big and also is a pain when I want to add
a
quick target to a subdir build.xml.
I'm kind of stumped here for a good solution, but I really appreciate all
the feedback ... so far.
Thnaks.
John
-----Original Message-----
From: Christian Holmqvist, IT, Posten
[mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 19, 2002 3:03 AM
To: 'Ant Users List'
Subject: SV: Ant design question(s) - #1
Hi!
> Best to explain by example. I have a root directory,
> underneath which are
> two subdirs, one for java and one for native code. I have 3 separate
> build.xml files, one in each directory. The way I have
> written it now, the
> root-level build.xml sets some environment variables that the subdir
> build.xml's use (e.g. destination directory). I figure this
> is good because
> these are defined in only one place. But it's bad because the two
> build.xml's in the subdirectories are not standalone - they
> have to be run
> through the main build.xml else there are undefined variables.
> So the question is, is there a smarter way to do this?
As many others have sade before, it is nice to use a build.propertie file
to
define common properties.
BUT there is a bit of catch 22 in this, some form of define has to be done
to find the propertie file. This is why I choose the same solution as you
did.
I made a init task in the sub_build.xml file that ensures that the $ROOT
property is set (else it will fail) and since all targets depends (in one
way or another) on the init target I can know that the sub_build.xml is
called throw the build.xml file.
There are several advantages in this, in the build.xml file I can check
that
dependent project is uptodate ahead of building another project. I can also
ensure that the correct .jar files are lokated in the /lib directory for
the
version of the build that I'm performing.
I have also created a "user_view_build.xml" file that opens up just those
targets that I want my users to be able to perform (for example developers
and config manager don't have the same "user_view_build.xml" file).
This might seem kind of complex but I use very little none built in taskes,
the build.xml files are very small and clean.
The main thing to remember is that it is VERY different to develop ant for
a
small tight group where all are "ant aware" and to develop ant for a large
none ant-aware group.
Ohh well, hop you have a nice anty time *smile*
Cheers Christian Holmqvist
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
