https://issues.apache.org/bugzilla/show_bug.cgi?id=45612
--- Comment #3 from Oran Fry <[EMAIL PROTECTED]> 2008-08-18 19:05:58 PST --- (In reply to comment #1) >I've seen you mail to the dev list (In reply to comment #2) >I'm not sure this feature is compatible ... with Ant's target concept Please do not go by the email I sent to the dev list - I have cleaned up a lot of the details since then. In the email I referred to the feature as "target addressing", but I have since I realized that "project addressing" is more appropriate, and more compatible with Ant concepts (and code). (In reply to comment #1) >I failed to understand the rationale immediately (and ran out of >time for deeper thoughts) Fair enough! It started as a way to resume a failed build. The first time I saw a chance to extend Ant was when I started working with Greenstone3. The build is done with Ant, with lots of use of antcall and it's a very long process. If the build failed partway through (say, because some environment variable was set incorrectly), you could fix the problem and rerun the target where the build failed, which was great. But the problem was, it would not then carry on with the rest of the build - all you could do was to start the build from the beginning again. There was inevitably some bandwidth, cpu, and time wastage rerunning the same targets again, despite Ant's ability to avoid repeat operations. The solution was to implement a system where you always specify the same high level target on the command line (an "entry point" target, something like "build-greenstone3"), but with the option of telling Ant to resume the build from the given subproject (i.e., antcall). Addressing was a natural way to tell Ant which subproject to resume from (the -from option), and once that was implemented it was worth it to add the complimentary -to and -descend options. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
