ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 35464] New: - Add a dry run mode
Date Wed, 22 Jun 2005 11:43:03 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=35464>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=35464

           Summary: Add a dry run mode
           Product: Ant
           Version: 1.6.5
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Core
        AssignedTo: dev@ant.apache.org
        ReportedBy: francois.robert@unisys.com


I am new to Ant. We are using it in a Configuration Management context. Here is 
the situation :

Preliminary definition: Targets in a build.xml files can be broadly divided into 
two categories : Target that produce a "deliverable" (ie. something that will be 
passed to the customer/QA group/etc... Typically, a deliverable is a jar file, 
an executable, a shared object...) and those that don't (deployments, cleanup, 
tests etc...)

- We have a bunch of distinct build.xml files, which are used to build Java-
based deliverables (for now). Each Ant file typically builds a handfull of 
deliverables.
- The deliverables can be built in debug or release "flavor" (or maybe some 
other, like "instrumented" ...)
- The building process of all deliverables is sprayed accross all the different 
ant files.
- Deliverables have dependencies on other deliverables, whose target is not 
necessarily located in the same ant file. In other words, the entire build 
process must run all build.xml files, but in a specific order, passing specific 
targets.

The problem is : I neeed to determine (automatically) : 
- What are the deliverables that can be produced by all the ant files.
- What target in what file will produce what deliverable(s).
- What target depend on what other target in which ant file.
- The "flavor" of each deliverable.

The objective is to create automatically a "master" ant file that can produce 
all the deliverables. (by calling <ant> or <subant> against the right file and

the right targets, with the right expression of dependencies).

To achieve this, a minimum parsing of each build.xml is necessary, but without 
execution (or rather: replacing the execution of most task with emitting on 
standard output what would be executed. A few tasks, such as <ant>, <subant>,

<property> and the like needs to be "executed", however). This is what I call a 
"dry-run". 
Ideally, for my particular need, the "dry-run" should span multiple ant files 
(but that may not fit too well with the general philosophy of having Ant 
executing a single file at a time). A dry run mode would also what are the 
dependencies of each target and what are the deliverables produced by each 
target (and what is its "flavor")

I have tried to implement the scenario above and here are some observations I 
gathered during this attempt (for what it's worth).
- I first thought of parsing the Ant file through the Ant API (a bit like the 
Grand tool) but then I am a bit stuck with property resolution and sub-builds 
execution.
- A second approach that I then looked into was to redefine core and optionnal 
tasks with appropriate no-op task (except for sub-builds and <property> tasks 
and maybe others).  I then thought that such a definition could done inside each 
task class (with a dry-run flag added or maybe with some OO trick), or that a 
modified class loader pointing to a different set of class files may do the 
trick. 
- The definition of "deliverable" is fuzzy. Typically, in any build process, 
some "intermediate compilation products" (static library, object files, class 
files etc...) are also produced. Those usually don't qualify as deliverable 
because they are consumed by some other subsequent build action. Tracking what 
is produced and consumed by the various steps is not easy (and may well be 
impossible with <taskdef>s, unless the task writer somewhat hints what are the 
inputs and outputs of its task) but is essentially what allows to distinguish 
between "deliverables" and mere temporary files. It also allows to assign a 
"flavor" to a deliverable: If we track the compilation settings (debug, release, 
instrumented, optimized, whatever...) of intermediate products, then you can 
assign a "flavor" to each deliverable down the chain as well. You can also flag 
situations like mixing different flavors in the same deliverable/intermediate 
product (which is most of a time a mistake).

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message