[jdom-interest] XPath and Jaxon
jdom at tuis.net
Mon Sep 12 19:06:32 PDT 2011
I had a look at the Jaxon JDOM plugin, and there are a few things I
don't like about it... (not least of which is the headache of having to
give attribution, etc/ as part of the license if we copy it). There are
also a lot of inefficiencies in the code where it uses long-winded
mechanisms for getting JDOM information. Finally, I am finding bugs in
the implementation of the DocumentNavigator.
Given the headache of 'cloning' and 'fixing' the existing Jaxen/JDOM 1.x
interface (and getting the right attribution/compliance with the
license), it seems to make sense to write our own interface layer, and
I have already started doing that, and it seems to be working OK now (I
am working on some more esoteric issues though). It is neater, more
logical, and more 'JDOM-like' in it's implementation. It also allows me
to write some working jUnit tests
I have done Jaxon Handlers before for other projects, and it's a
(relatively) simple interface to plug JDOM in to. It is also giving me a
bunch of ideas for what would be useful in JDOM2.
This is a deviation from the original plan though, of first doing a full
unit-test coverage before making changes.
It would seem, in general, that it is time for an progress update, but I
want to address this issue independently.
Bottom line is: Current XPath is broken in jdom2. - can't write *any*
tests for it. Three options available:
1. Get Jaxon to update the jaxon code (slow, and really the 'plugin' is
JDOM code, not Jaxon code)
2. Copy/clone the Jaxon JDOM handler, fix the bugs, and sort out the
3. re-implement the interface in a more JDOM-natural way.
My preference is for 3, but, none of the options allow me to (easily)
test the existing code *before* making changes. I am very reluctant to
commit any Jaxon-derived code at all until this decision is made, which
means the github code would not pass testing....
So, I think I will tackle the last remaing chunk of code (transforms),
and come back to the XPath later.... (Wednesday?)
On 12/09/2011 12:38 PM, Jason Hunter wrote:
> It wasn't really discussed.
> My guess on why it happened this way is Jaxen was a new project then and decided to provide support for the existing object models rather than ask them to support Jaxen.
> On Sep 12, 2011, at 2:45 AM, Rolf wrote:
>> Indeed, that's the way I see it (and it's also what I am doing to get the testing done.
>> It is also what I see as the 'logical' way it should be done, which is also why I am asking... why was it not done that way first time around?
>> On 12/09/2011 1:52 AM, Thomas Scheffler wrote:
>>> Am 12.09.2011 02:43, schrieb Rolf:
>>>> What is the right way to do this migration...?
>>> as I understand the Jaxen code correctly you have to implement the
>>> Navigator interface to add support to any library.
>>> I would conclude that you have to move the JDOM-Jaxen-Code completely to
>>> JDOM. This way there is no circle dependency anymore and no need to fork
>>> any version of Jaxen here. As JDOM2 is an different library than JDOM
>>> and you are free to do this. JDOM2 would than depend on Jaxen and that's
>>> To control your jdom-interest membership:
>> To control your jdom-interest membership:
More information about the jdom-interest