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