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=14521>. 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=14521 Clearly document that if/unless are based on existence of attr, not boolean value Summary: Clearly document that if/unless are based on existence of attr, not boolean value Product: Ant Version: 1.6Alpha (nightly) Platform: All OS/Version: All Status: NEW Severity: Normal Priority: Other Component: Documentation AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] E.g. a <target name="..." if="some.prop"/> will run if the property is set, even if empty, e.g. this will print "Ran": <?xml version="1.0" encoding="UTF-8"?> <project default="all"> <property name="foo" value=""/> <target name="all" if="foo"> <echo>Ran</echo> </target> </project> This seems a poor design, since once any piece of the script sets such a property (e.g. loading a build.properties file), there is no way to turn it off, even with -D from the command line. You need to do weird workarounds like: <?xml version="1.0" encoding="UTF-8"?> <project default="all"> <property name="foo" value=""/> <property name="foo.is.${foo}" value="what a hack"/> <target name="all" if="foo.is.true"> <echo>Ran</echo> </target> </project> I can't imagine this is obvious to an inexperienced Ant user: after all, boolean-valued attrs of tasks accept "true", "false", etc., so the different behavior for if/unless is confusing. While it makes some sense to permit any value (not just "true") to satisfy the condition, I would have expected at least that "" (empty string) would count as false - but it counts as true too. If this behavior is really intentional, or cannot be changed for compatibility reasons, please improve the documentation a bit. docs/manual/using.html#targets does describe the actual behavior, but fails to call attention to how unexpected it might be for some users. It also fails to suggest ways to let the property used by if/unless be overridden even when there is a true default, such as my "hacky" example above. Anyway I might suggest printing a warning when a property used in if/unless is set but has the value "false", since this very likely means that the script writer or user does not understand what is going on. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
