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