DO NOT REPLY [Bug 45612] [Patch] Subproject Addressing and Simulation Mode

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=45612





--- Comment #5 from Oran Fry <or...@ocf.co.nz>  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.