https://issues.apache.org/bugzilla/show_bug.cgi?id=45612
--- Comment #5 from Oran Fry <[EMAIL PROTECTED]> 2008-09-07 17:05:58 PST --- The basic idea of the Addressing feature is that it allows a user to see the project tree, and make use of its structure. It is an general tool which could have many uses, and users may find new ways to use it that even I haven't thought of. It's not just about resuming a build; that is only one way it can help. Here are some of the uses I have put addressing to: * Viewing the structure of an unfamiliar project (e.g., one downloaded from the internet) * Resuming a failed build that is not well designed to avoid repeat operations * Resuming even well designed builds which inevitably take time to skip over operations which are already done (especially when the checks involve checking files on the internet) * Stepping through a build, to examine the state of files etc. as the build progresses * Executing the first part of a build in preparation to execute the second part later (E.g., If I'm waiting for the files needed for the second part) * Skipping over an unstable or problematic part of a build without having to modify the build file. (e.g., If an build is failing at a particular target but you are able to perform that operation manually.) * Expressing the relationship between targets. Addressing lets the user see which targets are being called as dependencies and which are being called as subprojects. If "do-b" and "do-c" are subprojects of "do-a", this expresses that "b" and "c" they are *part of* the process "a". If "do-b" and "do-c" are dependencies of "do-a", this expresses that "b" and "c" are things which must be done *before* process "a". For a user, seeing these relationships makes a build easier to understand. * Avoiding repeat execution of "init" targets. Rather than making every target depend on "init", I just make the entry point target(s) depend on "init". Since the build is always entered from the entry point target, the init target will always be executed when the build is invoked. And it will only ever be executed once, unlike in some projects where it is executed multiple times as a result of the absence of backwards propagation in ant. It also saves you putting 'depends="init"' on every target. * Checking for links in an antfile to other antfiles (i.e., use of the <ant> task. Done by using ant -sim -addressing.) * Addressing works for any ant file, whether the developers are aware of addressing or not. But if the developers are aware of addressing, they can design their builds to make special use of it and so get the most out of it. I have found the addressing option (in conjunction with the sim option) a pleasure to use as I have developed and used the nightly release snapshot system for Greenstone. It is actually very simple as far as the code changes are concerned - I have added just two if blocks to check whether a call to a task should proceed in light of the addressing and sim options specified on the command line, and the rest is just the code to pass those options around, some display stuff, and a class to represent an address. It has many uses, and I have had good feedback about it. So I think there is a lot of bang for your buck! -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.