Hi Joel, the build dependencies between 1.6.1 and 2.0 changed in the following way: * Jaxen 1.1-beta-6 -> 1.1.1 * pull-parser 2 -> 2.1.10 * xpp3 1.1.3.3 -> 1.1.4c The test dependencies will probably change more, but perhaps I will remove some dependencies from the list rather than append some new.
I have no contact with Jaxen authors, I found solution concerning developer access and domain with Maarten Coene and James Strachan, one the original authors. All the best, Filip 2008/10/15 Joel Rosi-Schwartz <[EMAIL PROTECTED]>: > Hi Filip, > > On 14 Oct 2008, at 17:48, Filip Jirsák wrote: > >> 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. > > Apologies, I should have been clearer. The Eclipse Foundation is very > concerned that all software that is released by EF project is safe for > consumption by its adopters and users. Therefore all third party software is > checked for licence and copyright cleanliness. Essentially all the > Foundation wants to assure themselves of is that all of the software is > under an acceptable OS licence, that it was written by who the third party > says it was and that all authors agree (in some controlled fashion) that it > is okay for their work to be included in the distribution. It not really > onerous :-) and if you take a look at the wide range of third party software > that is included in EF projects you will see that it is not hard to pass > review. > > Every new release of library does need to be reviewed. But often is easier > on future runs if for no other reason than a relationship has been formed > with the authors already. > > Btw, do you have contact with the Jaxen authors. If so maybe you could > encourage them to contact us about this. > >> 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. > > That is a good question, and I think the EMO IP team would be better placed > to comment. Barb? > >> 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. > > We would appreciate any help you are able to provide. > > I have not followed the history of Dom4J for some time, but a gather that > the original project went dormant and you brought it back to life. Are you > in contact with any of the original authors? > > Many thanks, > Joel > >> 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 > > -- 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
