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]>
