Hi Michael, just a hint: what's about <target/>'s if/unless attributes... BTW: How would you handle this in eclipse? Cheers Rainer
> -----Original Message----- > From: Michael Cepek [mailto:[EMAIL PROTECTED] > Sent: Tuesday, May 17, 2005 11:17 PM > To: user@ant.apache.org > Subject: nontrivial dependencies > > > I've been trying for a very long time now (many man-days) to > create Ant build scripts to handle our new corporate project. > > I've been using Ant for over 3 years, and programming > professionally for over 25 years. > > Despite all that, I cannot seem to get Ant to do what we need > on this project. I am becoming extremely frustrated and > disillusioned with Ant as a build tool. Yet in my heart I > feel like there is an elegant solution. > > Perhaps some gurus can enlighten me? > _ _ _ _ _ _ _ > > Our project has a pretty basic layout: > > dev/foo/build.xml > dev/foo/config/runtime.properties > dev/foo/config/log4j.properties > dev/foo/lib/ > dev/foo/log/ > dev/foo/src/cpp/... > dev/foo/src/java/com/company/foo/admin/ > dev/foo/src/java/com/company/foo/db/ > dev/foo/src/java/com/company/foo/controller/ > dev/foo/src/java/com/company/foo/util/ > > Note the (as-yet undefined) src/cpp/ subtree for C++ code. > > Here is a sample layout for one of the java package directories: > > dev/foo/src/java/com/company/foo/util/build.xml > dev/foo/src/java/com/company/foo/util/DbUtils.java > dev/foo/src/java/com/company/foo/util/StringUtils.java > dev/foo/src/java/com/company/foo/util/classes/ > dev/foo/src/java/com/company/foo/util/javadoc/ > dev/foo/src/java/com/company/foo/util/test/testAll > dev/foo/src/java/com/company/foo/util/test/testDbUtils.java > dev/foo/src/java/com/company/foo/util/test/testStringUtils.java > > Our team needs to be able to use the following Ant targets > from within ANY of the top-level java package directories > (xxx = one of these package names: admin, db, controller, and util): > > compile - compile .java into .class files which are put into > company/foo/xxx/classes/ for package xxx only. > > build - create lib/xxx.jar (containing non-test files) and > create lib/xxx-test.jar (containint test-only files); > depends on compile. > > test - run unit tests for package xxx; depends on build. > > javadoc - put javadoc for package xxx only into the > company/foo/xxx/javadoc directory. > > clean - delete buildable files for xxx only. > > We also need these targets: build-all, test-all, > javadoc-all, and clean-all. These would build everything for > both Java and C++. > > We need to use these targest both from the command-line AND > from within our IDE (currently Eclipse). A command-line example: > > $ cd dev/foo/src/java/com/company/foo/util > $ ant clean-all test > > The above would first delete all buildable .jar, .class and > .dll files from the whole project. Then just the "util" > package would be compiled, built, and unit-tested (we are > using JUnit). > > We would prefer to rely on Ant's Core Tasks only, if at all possible. > > The dev/foo/build.xml file uses <property > file="config/runtime.properties"> to bring in the common > properties definitions like: > > SRCDIR=${basedir}/${ant.project.name} > CLASSES=classes > LIB=lib > CONFIG=config > LOG=log > JAVADOC_FTP_HOST=192.168.12.34 > JAVADOC_FTP_DIR=html/foo/api > JAVADOC_FTP_USR=anonymous > JAVADOC_FTP_PWD=none > JUNIT_RUNNER=junit.textui.TestRunner > > Finally, we need each package to first compile and/or build > any packages on which it depends. > > [Doesn't everyone need to do this?] > _ _ _ _ _ _ _ > > I have tried many combinations of <import>, <subant>, <ant>, > <antcall>, <target depends="...">, and <macrodef>. > > I have hit brick walls every time (not Ant bugs). > > For example: To use Ant from the command line in any package > directory, there needs to be a build.xml file in each. > Ideally these would be as small as possible to minimize Ant > script code replication, ease maintenance, and simpify the > creation of new packages. I tried many ideas along the lines > of Joe Schmetzer's post on 9-May-2005 to this list. Nothing > has worked out. > > My favorite aspect of Joe's solution was having each simply > "name itself" using the <project name="..."> attribute, and > then rely on ${ant.project.name} to know what the originating > package was. Each of those package-level Ant scripts was > perfectly minimal: > > <project name="com/company/foo/admin" > default="usage" basedir="../../../../../.."> > <import file="${basedir}/build.xml" optional="false"/> > </project> > > Anyway... > > One of the key issues is: how to handle the dependencies? > > At the moment I'm out of time to write more (my carpool is > here). This post is probably plenty long anyway. > > Has anyone put together solutions like this? Care to share > some working scripts? Any other suggestions or > recommendations? Thank you. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
