Peter (and others)
As threatened, I've incorporated your HDX changes along with some
ant-based source code preprocessing which allows HDX to build under either
Java 1.4 or 1.5. The new Level 3 DOM methods don't do anything, they
mostly just throw DOMExceptions, so this is a patch up job - HDX does
not implement the DOM which is used in Java 1.5 (the contract defined
by the DOM Level 3 specification and javadocs is violated), but it will
build and effectively provide DOM Level 2 functionality under Java 1.5.
I've noted this fact briefly in the javadocs. It would probably(?) not
be a massive job to provide DOM Level 3 properly, but it's not trivial
either.
Norman: in order to accommodate this I have removed the get/setBaseURI
methods from HdxDocument, since their signatures clash with some new
Level 3 methods for the Node interface. Since both these methods
were package-private, and not used anywhere in the HDX package,
I don't imagine there's much objection to this.
I have also modified one of the tests so that it works under 1.5 - it
was complaining about finding a CDATA node instead of a Text node with
the same content. I don't think this is an important difference,
so I removed the CDATA marked section from the test string - see
CVS history comments for HdxTest.java for details.
As I said before, I've done similar things to the VOTABLE package,
though this really does implement a Level 3 DOM when compiled under
Java 1.5, since it delegates all the hard work to whatever DOM
implementation it gets from JAXP.
I've also modified some .properties files so that there are no longer
circular dependencies which java 1.5 objects to at compile time.
Most of the starjava set now builds, installs and tests using either
Java 1.4(.1) or 1.5(.0) therefore. There is still one problem however.
The "javadocs" and "test" targets for treeview fail at 1.5, again
because of circular dependencies. In both cases it sits there
for a while and then throws an OutOfMemoryError.
I'm reasonably sure this is because the treeview's installed.classpath
contains both splat.jar and topcat.jar, while the manifests of those
two have class-paths which point to ../treeview/treeview.jar.
The rest of the build is happy with this, but javadocs & test fail.
Peter, can you think of a good way round this? If it's going to be
a pain to do it properly, I could just construct a class path by hand
in treeview's build.xml for use with the javadoc and test targets
which exclude splat & topcat. The right answer of course is to have
treeview split into a library and applications package - it was getting
perilously close to the top of my to-do list before VOGON came along.
If you think it's the only reasonable way to proceed though I could
bite the bullet anyway.
Note - apart from the unit tests, I haven't attempted to verify whether
anything works yet.
Mark
--
Mark Taylor Starlink Programmer Physics, Bristol University, UK
[log in to unmask] +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/
|