dom4j 2.0 will as backwards compatible as possible except necessary changes needed by upgrade to Java 5 (generics, W3C DOM 3 etc.) It means no new dependencies and only a little of new code. I don't know what exactly IP review means - if it means license and dependencies review, there will be no change between 1.6.1 and 2.0. In fact I plan update dependecies versions to the most actual ones, but I hope it doesn't matter. By the way, I plan to release maintaince version 1.6.2 with the same dependencies version update - for example dom4j should go with release version of Jaxen instead of beta version.
If IP review means code review in respect of algorithms and software patents, there is some new code in LazyList class. I'm afraid I can't help with this in that case, because I live in country where software patents doesn't exists fortunately and I don't know anything about them. I wrote LazyList class myself without help of any other code, but I don't know if it matter. I will try to answer your questions as best I know. Need to say that I'm not the original author of dom4j. I want to revitalize dom4j and I write some code for dom4j 2.0, but source code of dom4j is relativelly new for me. However, I hope that I will be able to help you. All the best, Filip 2008/10/14 Joel Rosi-Schwartz <[EMAIL PROTECTED]>: > 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 > -- Filip Jirsák [EMAIL PROTECTED] ------------------------------------------------------------------------- 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
