Thanks for the reply Filip. I should have mentioned that we are working against 1.6.1. I am not sure if we are prepared to move to 2.0 because it require a new IP review process. In case we do consider is 2.0 backwards compatible with 1.6.1 except in regards to the removed deprecations?
We have limited resource to tackle this modification, so we really have to consider carefully how we move forward with it. If you (or others on the Dom4J team) are prepared to assist us (minimally with guidance and answering questions) then we can consider do a proper job and a patch. Otherwise we will have to do a quick'n'dirty to get us by. Would you be in a position to assist? Many thanks, Joel On 14 Oct 2008, at 09:03, Filip Jirsák wrote: > Hi, > I don't know how deep is Jaxen interlaced in dom4j code. On the other > hand I think it is in dom4j intention to afford interfaces which can > have different implementations. Dom4j itself has org.dom4j interfaces > and org.dom4j.tree, org.dom4j.dom and org.dom4j.bean implementation, > so why not use the same principle for XPath? > > I don't think it is good idea to implement this in 2.0 branch, > probably it will be better to wait for 2.1. I plan intensify usage > org.dom4j.DocumentFactory to offer QName cache implementation for > document instead of one hardcoded cache, I think DocumentFactory > should offer XPath implementation in the same way. Than you can use > both Jaxen and JAXP in one source code. > > Looking in JavaDoc it seems there are such methods in DocumentFactory, > so it probably means to generalize them only. > > Probably you know source code repository for dom4j 2.0 is in Mercurial > repository http://freehg.org/u/FilipJirsak/dom4j/ . Patches are > welcome :-) > > Regards > > Filip Jirsák > > 2008/10/12 Joel Rosi-Schwartz <[EMAIL PROTECTED]>: >> Hi, >> >> First apologies for spamming both lists, but I noticed that the dev >> list is not used a great deal. >> >> I am representing the Eclipse Foundation (EF) in an effort to use >> dom4j in its full glory within EF projects. The EF is very careful >> about the IP pedigree of all third party libraries used in EF >> projects. There is no problem with dom4j itself and in fact it has >> been approved for reuse for sometime now. The problem is with the >> XPath support dependency on Jaxen. The EF has tried several times to >> communicate with the Jaxen team to confirm some IP related issues, >> but >> have failed to receive a reply. >> >> I have therefore decide that the way forward is to attempt to add >> JAXP >> support for the XPath functionality. Would the Dom4J team be willing >> to co-operate with us in accomplishing this? I do not think it is a >> matter of replacing Jaxen, but rather to add another means of >> supporting XPath. A test can then be performed at runtime to >> determine >> if Jaxen is available and if not use JAXP if it is. >> >> We would very much appreciate any assistance you folks could give us >> in this matter. >> >> All the best, >> Joel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ dom4j-dev mailing list dom4j-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dom4j-dev
