Community
Participate
Working Groups
All of the Ant code should be moved to use the JAXP interfaces etc. Should only impact the Ant UI.
I have made the adjustments to the Ant UI plugins (not yet released) The problem is with the test suites and ensuring that the tests do not rely on parser specific behavior (which I believe they currently do). Ant's plan: Have no implementation specific dependancies on Xerces. A user running Eclipse on a 1.4 vm, Ant in the same VM as Eclipse ---> Xerces VM ships with A user running Eclipse on a 1.4 vm, Ant in a 1.4 separate VM ---> Xerces VM ships with A user running Eclipse on a 1.4 vm, Ant in a 1.3 separate VM ---> User will have to manually add the required Xerces JARs to the Ant runtime classpath
Released: org.apache.ant: removed <requires> statement for Xerces org.eclipse.ant.core: removed Xerces from the classpath and as a required project for the build path. org.eclipse.ant.ui: reworked all parsing to use the JAXP interfaces (changes to Parser, AntEditorCompletionProcessor, AntModel and XMLElement). Removed Xerces from the classpath and as a required project for the build path. Removed <requires> statement for Xerces. org.eclipse.ant.tests.ui: reworked all parsing to use the JAXP interfaces (changes to CodeCompletionTest, EnclosingTargetSearchingHandlerTest, AbstractAntUITest). Removed Xerces from the classpath and as a required project for the build path. Removed <requires> statement for Xerces. Three tests still fail...need to see if bad tests or changes resulting from the parser change.
The Ant plugins no longer directly reference the Xerces plugin. The Ant Editor code assist is not as good as it was before but I do not believe that the average user will notice. We will log these as separate issues that can be dealt with or not as we have the time. See bug 45244.
Please verify DarinW.
Darin, just curious how you worked through the Locator/column number problems that we discussed. (no doubt others (like PDE) will have the same problems)
We haven't fully (bug 45244) but basically we added support to pass around the underlying AntEditor IDocument and then use the searching capabilities (FindReplaceDocumentAdapter) and the ability to find line numbers and therefore column numbers using offsets.
We were talking about it around here and one suggestion that McQ had was to wrap the input stream in your own stream and keep track of column position by counting #read calls (and watching for CR/LF). Not sure if that is any easier or not...it would probably be easy to get confused along the way.
And all the fun of multiple platforms and different line delimiter lenghts... But it is another idea we could investigate..thanks
Verified.
