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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
