DO NOT REPLY [Bug 22020] - addition to task

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22020>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22020

addition to <target..> task

gus.heck@olin.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |



------- Additional Comments From gus.heck@olin.edu  2003-08-04 20:36 -------
When was this targets beginning with - thing introduced? Has it been there all
along? if so where is it documented I know I looked at one point for some form
of public/private target distinction and missed it (which isn't a very good test
at all, but there you have it) 

After testing it myself, I found that anything that begins with "-" is parsed as
an option, but what happens when things change? for example what if support for
"--" to prevent further option recognition is added? Sounds like a perfectly
reasonable feature if you don't know that people are using -internal1 to keep
targets hidden.

Also, the public/privateness is hidden in the text of the target name, rather
than out in an atribute of it's own where it can be easily changed or
programatically considered (perhaps in resolving imports? can an imported ant
file's "private" targets be called? What about overriding them?)

Steve's workaround is cool, clever and provides exactly what I want in terms of
hiding targets, but I am reopening because I think it also looks like a
coincidental result of option processing quirk and a more robust system that
doesn't push funtionality into the target names could be subsituted. This is
afterall only an enhancement request. (maybe after I move I'll try to write
this, if Verizon doesn't go on strike and deprive me of a phone line in my new
appartment) Others are of course welcome to beat me to it :)

I also noticed that this issue sort of came up in bug 3807 but the reporter
seems to have ignored the response given. Perhaps 3807 should be marked a dup of
this (since this one has more info on it already)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org