ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Brown" <brow...@ociweb.com>
Subject assertion changes
Date Fri, 16 Nov 2001 17:25:12 GMT
I have been using my own modified version of the Java task that allows assertions to be anabled
at runtime.  The attached changes are only slightly different from a change I suggested a
few weeks ago.  Is there any interest in adding this to the tree?  If there is, I will move
ahead with adding the necessary documentation etc.

To summarize...

javaassert.diff = diffs for org.apache.tools.ant.taskdefs.Java
AssertionArgument.java = new class for org.apache.tools.ant.taskdefs package
assertTest.zip = a test kit including a buildfile that uses the new functionality

This change introduces a new optional argument to the Java task called "systemassertions".
 This is a boolean attribute that simply enables or disables system assertions.

This change also introduces optional nested elements <enableassertions> and <disableassertions>.
 Each of these have the optional attributes "package" and "classname".  Exactly 0 or 1 of
those attributes may be used per element.  That is, an enableassertions or disableassertions
element may NOT contain both the package and classname attributes.  This is enforced in the
code.  If neither attribute is specified, then all user assertions are enabled or disabled.
 If the package attribute is specified, then assertions will be enabled or disabled for the
named package and all sub packages.  If the classname attribute is specified, then assertions
will be enabled or disabled for that class.  Any number of enableassertions and disableassertions
elements may be combined and will have a cumulative effect exactly like the command line arguments
to the "java" command have.

Forking must be enabled for this to take effect.

It may not be advisable to check the vm version for >= 1.4 before allowing these options
because the vm that is being launched isn't necessarily the same vm that the task is executing
in.  In my opinion, this "functionality" would not be funcionality at all, but would be a
problem in some circumstances.  Of course, this implementation is entirely passive in that
it does not impose anything at all on users not interested in taking advantage of it.

Please let me know if you have any comments and/or questions about this.

Thanks.



Jeff
--
Jeff Brown
Senior Software Engineer
Object Computing Inc.
http://www.ociweb.com/

Mime
View raw message