ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 18506] - Determine projecthelp non-main targets from prefix in target name
Date Mon, 31 Mar 2003 09:36:03 GMT
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=18506>.
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=18506

Determine projecthelp non-main targets from prefix in target name





------- Additional Comments From j.c.yip@computer.org  2003-03-31 09:36 -------
Heh, just learned that the "-" prefix was a trick.  Will this continue to be 
supported in future releases?

You shouldn't have said "It's for your own good."... :)

As a counter argument, differentiating entry points and describing targets are 
two logically separate tasks.  It's not immediately obvious to a new user that 
adding a description marks a target as an entry point since why wouldn't you 
want to add descriptions to helper targets as well?  It would seem preferable 
instead to have a way to explicitly define an entry point or helper target that 
is not associated with descriptions.

I would expect most entry point target names to be chosen such that they are 
completely obvious in terms of what they do, even in a years time.  Those that 
are more complicated would have descriptions.

Borrowing an example from Java Development with Ant, starting p.350:

XML comment says "Default starting point", no description...
<target name="main" depends="ear"/>

I might have renamed clean to clean-all and would have removed the description.
I would have renamed build-db to build-sample-db
I would have removed the description from middlegen, xdoclet, compile, ejb-jar, 
and ear

I don't see how the descriptions added value at all.  I don't see how this is 
different from using comments to make up for bad identifier names.  We want 
clear, understandable, and maintainable build files which is not equivalent to 
descriptions on every entry point.

Mime
View raw message