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] - Add a dry run mode
Date Mon, 27 Jun 2005 13:53:01 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





------- Additional Comments From francois.robert@unisys.com  2005-06-27 15:52 -------
Firstly, I had a quick look at Maven. I am not too sure how suitable it is to my 
need. 
In fact, thinking again about my business use case, I now believe that I am 
trying to achieve something closer to "auditing" or "monitoring" (more passive 
behavior) than to "building" (more prescriptive behavior).
The idea is that I could have an overall view of that *can* be built from the 
source, which is a superset of what *will* be built. If something is added or 
removed, (even if should not be built) then I can see that as well.

Also, I thought about Steve Loughran's observation (comment #1) that "you need 
to know the output of all predecessors before you can predict what the next 
components will do, something that is done using the filesystem as a persistent 
state communication mechanism".
Indeed. 
This made me thought about the fact that merely *simulating* the chaining of 
input and output files on the filesystem could be enough to get a reasonnably 
meaningful set of deliverables. What I mean is that it is possible to define for 
many tasks which file(s) name(s) they will consume and which they will emit as a 
result (assuming successful completion). For instance, the <tar> tasks produces 
what is specified in the "destfile" attributes and consumes whatever file in the 
"basedir" folder whose name match/don't match the include/exclude patterns. 
<javac> produces a set of .class files from a certain set of .java files etc...
The idea would be then to simulate the lifecycle of files (production/
consumption/deletion), simulate the chaining and deduce from it what are the 
deliverables.

Of course this scenario breaks in various cases :
- <taskdefs> : In the current version of Ant, custom-define <taskdefs> have 
umpredictable inputs and outputs. If Ant mandated that taskdefs explicitely 
define their inputs and outputs, then this issue would disappear.
- output filename existence that depends on input file contents (and not merely 
on existence + Ant build file content). An example is linker output located in 
response files. I would suspect that this is truly hard to solve only if the 
input file is dynamically generated during the build. Otherwise, parsing of 
static input files (that exists before the build is started) can do the job 
(Admitedly could be very tedious to cover formats exhaustively, but feasible in 
theory).
- A variant of the previous case is when a task has unpredictable output(s) 
(like <get> when used with wildcards). Maybe a deeper/smarter simulation could 
help hint the filenames (ie in the case of <get>, obtain a directory listing of 
the files and track the filenames so obtained ?). Non-Ant scripting may be one 
sticky case where output may be truly unpredictable (<telnet> tasks with 
embedded shell scripting come to mind).

I also have the gut feeling in such a file-lifecycle tracking, outputs are more 
important than the input : In many cases, inputs are pattern-based, whereas 
output is well-defined.

Then there is the fact that simulating all targets (at least all target without 
predecessors) will cause different execution paths, that will yield different 
file chains, all of which needs to be simulated. That may well cause a 
combinatorial explosion of cases (?).

One of the things I don't know is how prevalent in practice are the cases that 
cannot be simulated (I suspect that there may be well more than the above 
mentionned three...).

Comments ?


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