Re: [dom4j-dev] Adding XPath support via JAXP
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
Re: [dom4j-dev] Adding XPath support via JAXP
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
Re: [dom4j-dev] Adding XPath support via JAXP
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
Re: [dom4j-dev] Adding XPath support via JAXP
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
Re: [dom4j-dev] Adding XPath support via JAXP
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 > -- 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
