A number of classes in grok depend on the com.sun.xml.tree package. My understanding is that this package is an implementation of the DOM API. As such, it should be possible to program against the DOM APIs, leaving the choice of DOM implementation up to the user (I would prefer to use xerces, for instance).
Is anyone aware of any hard assumptions that the implementation of DOM is Sun's? May I undertake the work to make this an interface-only dependency?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That would be fine with me. I don't recall making any specific use of the Sun implementation. The truthful answer is that when I wrote that code I didn't know much about XML and java implementations.
A more general approach would be welcome as long as, by default, it doesn't require any special configuration.
Jason?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Actually, Joao is now working on getting rid of the com.sun.xml stuff from the opennlp.common package, and then he was going to move on to Grok after that. If you don't mind waiting, it will come along soon enough, but if you need to have this changed over now, go ahead!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is he moving over to jaxp? I tried a naive search and replace and it worked for almost all cases except the ones where you use XmlDocument to *create* Document instances. For that we'd need to go to jaxp to hide the vendor-specifics for DOM parsing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We're moving things over to JDOM. I've already started using JDOM in Grok and OpenNLP, and have been quite happy with it. So, actually, a lot of the code will change as to how we traverse around XML documents, using the Java-centric methods of JDOM. If you want to do a quick fix that gets rid of the com.sun.xml dependency for the time being, though, that would be fine --- and, in fact, quite welcome!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A number of classes in grok depend on the com.sun.xml.tree package. My understanding is that this package is an implementation of the DOM API. As such, it should be possible to program against the DOM APIs, leaving the choice of DOM implementation up to the user (I would prefer to use xerces, for instance).
Is anyone aware of any hard assumptions that the implementation of DOM is Sun's? May I undertake the work to make this an interface-only dependency?
That would be fine with me. I don't recall making any specific use of the Sun implementation. The truthful answer is that when I wrote that code I didn't know much about XML and java implementations.
A more general approach would be welcome as long as, by default, it doesn't require any special configuration.
Jason?
Actually, Joao is now working on getting rid of the com.sun.xml stuff from the opennlp.common package, and then he was going to move on to Grok after that. If you don't mind waiting, it will come along soon enough, but if you need to have this changed over now, go ahead!
Is he moving over to jaxp? I tried a naive search and replace and it worked for almost all cases except the ones where you use XmlDocument to *create* Document instances. For that we'd need to go to jaxp to hide the vendor-specifics for DOM parsing.
We're moving things over to JDOM. I've already started using JDOM in Grok and OpenNLP, and have been quite happy with it. So, actually, a lot of the code will change as to how we traverse around XML documents, using the Java-centric methods of JDOM. If you want to do a quick fix that gets rid of the com.sun.xml dependency for the time being, though, that would be fine --- and, in fact, quite welcome!