Rob Williams

Greenhorn
+ Follow
since Jul 22, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Rob Williams

Please take note of the details of the copy task and the fileset type in the Ant documentation. The source directory attribute and the includes/excludes elements interact in a special way to determine the full path of each target file: each matching source file has the source directory prefix stripped from its full path name, then the target directory is prepended to the result to determine the full path name of the target file.

It appears that you need to properly set the source directory and target directory attributes of the copy task, and use multiple copy task instances (one for each source directory). Restructuring your directories might allow you to achieve all this with one copy task, but you are limited by the fact that the directory attributes do not support wildcards.
18 years ago
I forgot to address the inheritall and inheritrefs of the subant task. Yes, they could help to resolve part of my problem, and they may be able to be leveraged to solve all of it.

However, doing so would potentially involve a lot of extra properties with a lot of VERY careful management. The complexity seems prohibitive, and I think I would rather live with the inefficiencies instead. However, I have not yet tackled the integration of a release build into my new Ant infrastructure, or similarly complex processes that demand more property management.

We'll see...
18 years ago
Thanks for the reply. Yes, I am familiar with Ant's capabilities as documented at the links you provided. As the article says, doing a complex build such as mine is very much easier with the new capabilities of Ant 1.6.

I did indeed try creating composite targets such as rebuild = clean build, etc. Of course, this works in simple cases, but it does not scale. I don't want to have to create composite targets for every combination of my base targets and, if I did, I would encounter a combinatorial explosion of possiblities.

Ideally, I just want subant to handle multiple targets in a single invocation, just as though I were invoking Ant from the command line. Perhaps I need to post a request to their feature list.

Otherwise, it seems that my only solution is to reinvoke Ant via the exec task. Yuch!
18 years ago
Oops, my file structure was not preserved in my initial post. Here it is again:

Root
---Build.xml - invokes B/Build.xml, C/Build.xml, A/Build.xml
---A
------Build.xml
------src
---------*.java
---B
------Build.xml - invokes B2/Build.xml, B1/Build.xml, B3/Build.xml
------B1
---------Build.xml
---------src
------------*.java
------B2
---------Build.xml
---------src
------------*.java
------B3
---------Build.xml
---------src
------------*.java
---C
------Build.xml
------src
---------*.java

Thanks.
18 years ago
I have an issue with managing a multiple project build. Allow me to provide some context first.

I have a system of projects managed by an Ant build process consisting of multiple levels of Ant projects (Ant build scripts). A root Ant script invokes the subproject Ant scripts in the proper dependency order, down through multiple levels of subprojects.

As Ant is reinvoked for each subproject (via the subant task), the same target is invoked as for the calling project, all the way across and down the project tree.

Here is an example of a typical system file structure:
Root
Build.xml - invokes B/Build.xml, C/Build.xml, A/Build.xml
A
Build.xml
src
*.java
B
Build.xml - invokes B2/Build.xml, B1/Build.xml, B3/Build.xml
B1
Build.xml
src
*.java
B2
Build.xml
src
*.java
B3
Build.xml
src
*.java
C
Build.xml
src
*.java

I have a Windows script Ant.cmd that allows me to invoke Ant on the current directory, such that Ant executes the Build.xml script in that directory, which invokes the Build.xml scripts in the subdirectories as appropriate. So a typical invocation in a Windows command shell would be:

Ant clean build doc

Now, Ant's famous and desirable behavior is to evaluate the dependencies among the targets invoked on the command line, assemble an ordered list of targets to execute (including referenced dependencies but without duplicates), and then execute them in that order, WITHIN THAT SINGLE INVOCATION OF ANT.

But, when I invoke Ant on a Build.xml that invokes subprojects, my current Ant scripts result in A SEPARATE INVOCATION OF ANT FOR EACH TARGET ON EACH SUBPROJECT. This is due to the target dependencies being evaluated for the initial parent project (the one in the current directory), but the delegation occurs separately for each executed target (via subant). As a consequence, the subprojects are invoked repeatedly and many of their targets get executed repeatedly. The net effect is, for each subproject, as if I had instead entered the following into the Windows command shell:
Ant clean
Ant build
Ant doc

The problem with this behavior, of course, is that I do not get the same result from invoking a multi-target (e.g., clean build doc) build directly on a subproject as I do by invoking it on a parent project. In particular, the result is far less efficient since there are extra invocations of Ant on the subprojects and there are extra invocations of subproject targets.

However, the really big problem is that any property dependencies between subproject targets fail completely.

Consider a common practice for implementing debug versus release builds. The build target is typically implemented to default (via properties) to a debug compile. But, if you invoke the release target first, then those properties configure the compile for release mode instead. So
Ant build
gives you a debug compile, but
Ant release build
gives you a release compile since the release target sets the appropriate properties for release before the build target can set them for debug.

When invoking a subproject directly (in the current directory), this technique works as expected. But invoking a subproject through a parent project does not work because the release and build targets get executed IN SEPARATE INVOCATIONS OF ANT.

So, the solution is to get Ant to invoke a subproject with multiple targets ALL AT ONCE IN THE SAME INVOCATION OF ANT. But, it appears, none of the typical ways to invoke a subproject do this. The ant and subant tasks appear to only allow a single target in their target attributes, though I still need to do more thorough testing to be certain of this.

This results in my request: has anyone tackled this challenge of invoking multiple targets consistently down through a series of subprojects???

Thanks for your patience! ;^)
18 years ago