Community
Participate
Working Groups
When you make an error in an Ant build file (in this case xml that is not well- formed) and a target in the Ant file is on a project's build spec, you get a useful message in the console (first line below), followed by a very long stack trace. - The stack trace is irrelevant here (but could be written to log). - Could also have an error for hello.xml line 4 in the Eclipse Task view. === D:\eclipse\workspace\Hello\hello.xml:4: The content of elements must consist of well-formed character data or markup. at org.apache.tools.ant.ProjectHelper.parse(ProjectHelper.java:135) at org.apache.tools.ant.ProjectHelper.configureProject (ProjectHelper.java:85) ... etc etc etc
Defer until after release 2.0
Ant core is now passing along the original error message so we can display it in the error dialog instead of just "Build Failed" (see bug 21527). Ant core is looking at not printing out the stack trace to the console, but instead to the log file (with maybe a message in the console that it was written there). Some exceptions trace are useful depending what when wrong. No problem marker will be added to the task view. These type of markers cannot be deleted by the user, so we would need to manage these ourselves which is not possible if the ant build file reference by the tool is outside the workspace. We could just add a to do item to the task list, these can be deleted by the user. If you are interested in doing this work, please let me know (by opening a new bug report to explain the problem and the proposed solution). Right now, there are other higher priority items that we are working on.
Since we already rethrow errors we do not need to print them. The code has been removed.
I still think that some of the error dialogs provided by the UI should be more informative. For example, when a NoClassDefFoundError happens, the AntRunner throws a CoreException that wraps the original NoClassDefFoundError. The message in the CoreException tells the user to fix the Ant classpath but the original exception is hidden from the user (does not show in the dialog) and it usually contains important information like the name of the class that was not found. A details button showing information about the wrapped exception, IMO, is essential.
Clearing the later resolution
For classpath issues the name of the missing class is now displayed. In general the nested exceptions (inside an InvocationTargetExcetpion etc) are now exposed and presented with the correct message in the error dialogs.
Please verify (Jared).
Verified.
