Re: XPath and Jaxon

Hi All.

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 
start fresh.

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 
deployment/licensing/compliance issues.
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?)

Rolf

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.
>
> -jh-
>
> 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?
>>
>> Rolf
>>
>>
>> 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...?
>>>
>>> Hi,
>>>
>>> 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
>>> it.
>>>
>>> regards,
>>>
>>> Thomas
>>>
>>>
>>> _______________________________________________
>>> To control your jdom-interest membership:
>>> http://www.jdom.org/mailman/options/jdom-interest/[email protected]
>>>
>>
>> _______________________________________________
>> To control your jdom-interest membership:
>> http://www.jdom.org/mailman/options/jdom-interest/[email protected]
>

_______________________________________________
To control your jdom-interest membership:
http://www.jdom.org/mailman/options/jdom-interest/[email protected]