From jdom at tuis.net Sun Sep 11 17:43:43 2011 From: jdom at tuis.net (Rolf) Date: Sun, 11 Sep 2011 20:43:43 -0400 Subject: [jdom-interest] XPath and Jaxen Message-ID: <4E6D55BF.8060103@tuis.net> Well, that's embarrassing. a major road-block for writing jUnit test coverage has come up, and I guess I should have anticipated it... So, I have essentially done jUnit coverage of all the 'core' JDOM functionality (org.jdom2.* org.jdom2.input.* org.jdom2.output.*), leaving essentially just the transform and xpath code to go. SO I started the XPath code, and I can't even create an XPath instance, because the Jaxen library has internal references to org.jdom.* classes, not org.jdom2.* This is an interesting chicken/egg process, how does Jaxen build without JDOM, and yet, how does JDOM build without Jaxen...? Still, the basic problem is that I need to create a new jdom2-based 'plugin' for Jaxen, but that plugin is a part of Jaxen, not JDOM. For the moment I am going to re-implement the plugin on the JDOM side, but the implications are significant, and need discussions. What is the right way to do this migration...? Rolf From jhunter at servlets.com Sun Sep 11 18:32:29 2011 From: jhunter at servlets.com (Jason Hunter) Date: Sun, 11 Sep 2011 18:32:29 -0700 Subject: [jdom-interest] XPath and Jaxen In-Reply-To: <4E6D55BF.8060103@tuis.net> References: <4E6D55BF.8060103@tuis.net> Message-ID: <959B449F-223B-42FE-8BAA-4736ADB971EF@servlets.com> Put a forked version of Jaxen under the test area? -jh- On Sep 11, 2011, at 5:43 PM, Rolf wrote: > Well, that's embarrassing. a major road-block for writing jUnit test coverage has come up, and I guess I should have anticipated it... > > So, I have essentially done jUnit coverage of all the 'core' JDOM functionality (org.jdom2.* org.jdom2.input.* org.jdom2.output.*), leaving essentially just the transform and xpath code to go. > > SO I started the XPath code, and I can't even create an XPath instance, because the Jaxen library has internal references to org.jdom.* classes, not org.jdom2.* > > This is an interesting chicken/egg process, how does Jaxen build without JDOM, and yet, how does JDOM build without Jaxen...? > > Still, the basic problem is that I need to create a new jdom2-based 'plugin' for Jaxen, but that plugin is a part of Jaxen, not JDOM. > > For the moment I am going to re-implement the plugin on the JDOM side, but the implications are significant, and need discussions. > > What is the right way to do this migration...? > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From thomas.scheffler at uni-jena.de Sun Sep 11 22:52:43 2011 From: thomas.scheffler at uni-jena.de (Thomas Scheffler) Date: Mon, 12 Sep 2011 07:52:43 +0200 Subject: [jdom-interest] XPath and Jaxen In-Reply-To: <4E6D55BF.8060103@tuis.net> References: <4E6D55BF.8060103@tuis.net> Message-ID: <4E6D9E2B.1010207@uni-jena.de> Am 12.09.2011 02:43, schrieb Rolf: > Well, that's embarrassing. a major road-block for writing jUnit test > coverage has come up, and I guess I should have anticipated it... > > So, I have essentially done jUnit coverage of all the 'core' JDOM > functionality (org.jdom2.* org.jdom2.input.* org.jdom2.output.*), > leaving essentially just the transform and xpath code to go. > > SO I started the XPath code, and I can't even create an XPath instance, > because the Jaxen library has internal references to org.jdom.* classes, > not org.jdom2.* > > This is an interesting chicken/egg process, how does Jaxen build without > JDOM, and yet, how does JDOM build without Jaxen...? > > Still, the basic problem is that I need to create a new jdom2-based > 'plugin' for Jaxen, but that plugin is a part of Jaxen, not JDOM. > > For the moment I am going to re-implement the plugin on the JDOM side, > but the implications are significant, and need discussions. > > 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 From jdom at tuis.net Mon Sep 12 02:45:53 2011 From: jdom at tuis.net (Rolf) Date: Mon, 12 Sep 2011 05:45:53 -0400 Subject: [jdom-interest] XPath and Jaxen In-Reply-To: <4E6D9E2B.1010207@uni-jena.de> References: <4E6D55BF.8060103@tuis.net> <4E6D9E2B.1010207@uni-jena.de> Message-ID: <4E6DD4D1.3070603@tuis.net> 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/youraddr at yourhost.com > From jhunter at servlets.com Mon Sep 12 09:38:53 2011 From: jhunter at servlets.com (Jason Hunter) Date: Mon, 12 Sep 2011 09:38:53 -0700 Subject: [jdom-interest] XPath and Jaxen In-Reply-To: <4E6DD4D1.3070603@tuis.net> References: <4E6D55BF.8060103@tuis.net> <4E6D9E2B.1010207@uni-jena.de> <4E6DD4D1.3070603@tuis.net> Message-ID: 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/youraddr at yourhost.com >> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Mon Sep 12 19:06:32 2011 From: jdom at tuis.net (Rolf) Date: Mon, 12 Sep 2011 22:06:32 -0400 Subject: [jdom-interest] XPath and Jaxon In-Reply-To: References: <4E6D55BF.8060103@tuis.net> <4E6D9E2B.1010207@uni-jena.de> <4E6DD4D1.3070603@tuis.net> Message-ID: <4E6EBAA8.9090000@tuis.net> 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/youraddr at yourhost.com >>> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Mon Sep 12 19:54:07 2011 From: jdom at tuis.net (Rolf) Date: Mon, 12 Sep 2011 22:54:07 -0400 Subject: [jdom-interest] JDOM2 Update In-Reply-To: References: Message-ID: <4E6EC5CF.5020607@tuis.net> Time for another update The test-harness has been steadily growing. The numbers are interesting to track... (obviously, quality is what counts, but the numbers are interesting anyway). More importantly, though, at least 13 bugs were identified in the code so far as a result of the newly implemented tests. Additional issues have been identified as well. Some issues are not yet resolved. Back to the numbers... JUnit tests have gone from 179 to 630 (or so, I have some uncommitted tests in my copy). Code coverage is an interesting metric. There are two measures, one is the % of lines of code which were run/tested. The second is the % of the number possible code-paths that were taken in the code (including the 'obvious' if, while, for type conditions, as well as the more complex throws and try/catch/finally blocks). On their own they are useful metrics, but they are also somewhat unreliable, because some lines of code can never run, or some exceptions are never thrown. For example, the Content.clone() method is: public Object clone() { try { Content c = (Content)super.clone(); c.parent = null; return c; } catch (CloneNotSupportedException e) { //Can not happen .... //e.printStackTrace(); return null; } } In the above code, the catch block is impossible to test (super.clone() is Object.clone(), and as a result, the return null; line never runs. Thus, 100% coverage of Content is not possible. With that being said, the classes in the org.jdom2, org.jdom2.filter, org.jdom2.input and org.jdom2.output packages are now 'fully' covered by the jUnit test cases. The org.jdom2.adapters package is hard to test, because it requires loading up all the various parsers (crimson, oracle v1, oracle v2, etc.) and that needs some discussion... The org.jdom2.xpath package has some issues.... I have not started the org.jdom2.transform package yet... At this point then, counting the core, filter, input, and output packages, we are at 94.5% line coverage, and 94.1% of the code path coverage. I don't believe there is much more that can be done in the code to increase those numbers. The start-point numbers for the same packages were 48% line and 43% Additionally, the adapters, xpath, and transformer packages account for 'only' 11% of the code. What this all boils down to is that by the end of this week I expect that we can start working on the actual JDOM2 features we all want. Hopefully there are some good ideas out there for what features people want added to the list.... which, for the moment is reflected in the 'issues' related to the JDOM project at: https://github.com/hunterhacker/jdom/issues?sort=created&direction=desc&state=open&page=1 Additionally, progress has been made in back-porting a number of fixes to the jdom-1.x branch. This is getting ready for a release at some point. I am still looking for some Maven experts to step up and help in that process. Rolf On 08/08/2011 9:47 AM, Rolf wrote: > > Hi Everyone. > > Just to bring everyone up to date with JDOM2. > > The current plan is described on the wiki page: > https://github.com/hunterhacker/jdom/wiki/JDOM-2.0 > > The initial steps are described as: > > 1. Migrate the code from CVS to GitHub (keeping all the history). > 2. Create a branch for 2.0 > 3. Do the basic package renames. > 4. Fix the test case that's currently failing > (test_TCM__void_setExpandEntities_boolean) > 5. Upgrade the JUnit libraries and tests > 6. Use Cobertura to build up the JUnit test cases to get much better > coverage of the junit tests on JDOM (currently have only got 40% coverage > of the org.junit code from the JUnit test cases....). Fix any issues that > arise in untested code. > 7. Modify the core code and the test harness together to implement the > changes - document what changes are made so that we can get a list of rules > for migration from JDOM 1 to JDOM 2. > 8. Confirm any deviations from 'compatibility' with the jdom-interest > list to ensure that all changes are reasonable. > 9. Complete the migration, ensure all JavaDoc is complete. All Tests > are run, and code test coverage is 'complete'. > > > > The initial preparation steps (set up github, branches, basic package > rename, etc.) are done. See JDOM's new home at > https://github.com/hunterhacker/jdom > > What that means is that the current JDOM2 state is: > > JDOM2 looks exactly like JDOM, except it has a new package name, and all > the JUnit tests now are based on JUnit 4.8.2. > > In order to have a clear and documented migration path from JDOM to JDOM2 > we need to know and document all significant changes in the API. > > The most comprehensive way to do that is to ensure that the current JDOM > is well covered with unit tests, and that as we perform the JDOM2 > migration, we ensure that all unit tests pass, and if there are any reasons > to change the API, the unit tests get modified to adapt, and the deviation > is documented. > > In other words, in order to have the best possible JDOM2 it's important to > ensure that JDOM itself is very well covered for regression tests. > > > This is where JDOM2 is at the moment: building JUnit tests basically for > JDOM 1.1.1 > > No work will be done on any 'generics' or other API modifications until > the JUnit tests have adequate coverage for regression purposes. > > In order to track the progress of the regression testing, the tool > 'Cobertura' is being used to track the JUnit code coverage, and there is an > ant target 'coverage' that will do that for us. > > Currently the core JDOM code has about 40% coverage. This number should be > better than 95% before any real 'fun' work can begin. > > > My expectation is that the JUnit coverage will probably amount to about > half of the real work of the JDOM2 process. > > > In light of the above, this is also an invitation for assistance in doing > the hard work of building the best and most comprehensive testing we can. > > Once that is done we can get on with the fun part of doing the actual > migration (with the security of the unit tests to keep us on track). > > > > In order to set the expectations for JDOM2, I anticipate that any code > submission should be accompanied with as comprehensive JUnit testing as > possible. No changes will be accepted on existing code unless there are > first JUnit tests for that code. No patches/pulls/commits will be allowed > if they result in failing tests. > > > In order to facilitate the patching/submission process I am happy to > accept contributions in any reasonable format.... but, changes should be in > as small a 'chunk' as reasonably possible though, in order to make merging > and tracking as simple as possible. All changes will be attributed > appropriately. > > If you intend to get busy writing JUnit test cases, please drop me a note > so that I can co-ordinate with others writing tests so that there is no > duplication of effort. > > If you have any comments, questions, suggestions, please speak up! > > Thanks all, happy coding. > > Rolf > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jhunter at servlets.com Mon Sep 12 21:50:09 2011 From: jhunter at servlets.com (Jason Hunter) Date: Mon, 12 Sep 2011 21:50:09 -0700 Subject: [jdom-interest] XPath and Jaxon In-Reply-To: <4E6EBAA8.9090000@tuis.net> References: <4E6D55BF.8060103@tuis.net> <4E6D9E2B.1010207@uni-jena.de> <4E6DD4D1.3070603@tuis.net> <4E6EBAA8.9090000@tuis.net> Message-ID: <488925A3-240A-464F-B8B1-D65B6014E029@servlets.com> How about you copy the code (into the test area), modify it for the new packages, and write the tests against current baseline. Then author a new plugin for release. We can distribute the modified Jaxen code with the test library if we want. We already distribute the Jaxen library and its license. -jh- On Sep 12, 2011, at 7:06 PM, Rolf wrote: > 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/youraddr at yourhost.com >>>> >>> >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> From jhunter at servlets.com Mon Sep 12 21:55:32 2011 From: jhunter at servlets.com (Jason Hunter) Date: Mon, 12 Sep 2011 21:55:32 -0700 Subject: [jdom-interest] JDOM2 Update In-Reply-To: <4E6EC5CF.5020607@tuis.net> References: <4E6EC5CF.5020607@tuis.net> Message-ID: On Sep 12, 2011, at 7:54 PM, Rolf wrote: > At this point then, counting the core, filter, input, and output packages, we are at 94.5% line coverage, and 94.1% of the code path coverage. Excellent job! > The org.jdom2.adapters package is hard to test, because it requires loading up all the various parsers (crimson, oracle v1, oracle v2, etc.) and that needs some discussion... The adapters were from a time before JAXP. Is there any reason we'd want to keep them around? -jh- From mike at saxonica.com Tue Sep 13 01:10:04 2011 From: mike at saxonica.com (Michael Kay) Date: Tue, 13 Sep 2011 09:10:04 +0100 Subject: [jdom-interest] XPath and Jaxon In-Reply-To: <4E6EBAA8.9090000@tuis.net> References: <4E6D55BF.8060103@tuis.net> <4E6D9E2B.1010207@uni-jena.de> <4E6DD4D1.3070603@tuis.net> <4E6EBAA8.9090000@tuis.net> Message-ID: <4E6F0FDC.7000303@saxonica.com> > > So, I think I will tackle the last remaing chunk of code (transforms), > and come back to the XPath later.... (Wednesday?) > If you're looking at transform, it would be nice to see whether the interface to Saxon can be improved. At present, I think Saxon is being presented with a SAXSource and SAXResult so the JDOM source tree is reconstructed as a Saxon tree. Since Saxon is able to transform JDOM input directly, this is pretty inefficient. Using Saxon to deliver XPath 2.0 access, as an alternative to Jaxen, would also be quite feasible. (Also note: the Javadoc for org.jdom.transform.XSLTransformer is looking very dated.) Michael Kay Saxonica From jdom at tuis.net Tue Sep 13 03:10:52 2011 From: jdom at tuis.net (Rolf) Date: Tue, 13 Sep 2011 06:10:52 -0400 Subject: [jdom-interest] XPath and Jaxon In-Reply-To: <4E6F0FDC.7000303@saxonica.com> References: <4E6D55BF.8060103@tuis.net> <4E6D9E2B.1010207@uni-jena.de> <4E6DD4D1.3070603@tuis.net> <4E6EBAA8.9090000@tuis.net> <4E6F0FDC.7000303@saxonica.com> Message-ID: <4E6F2C2C.3010404@tuis.net> One of the reasons I have left the transforms to last is because I am least familiar with them. Essentially, unfamiliar with them... :( I have used transform to output DOM documents as files/strings, etc, but that's it. For the moment my immediate goal is to 'cover' what we have, so that we can have a regression baseline. I looked at the XSLTransform class and figured it largely just leverages the JDOMSource and JDOMResult classes. I thus have focused on those first. Testing those has been quite easy by simply 'piping' the results of a JDOMSource transform back in to a JDOMResult. The guts of that process is using the XMLOutoutter, SAXOutputter and SAXBuilder anyway which is well covered too. I think the improvement of the the efficiency of the process should be done after the regression baseline is established. I will push this through as an issue though: https://github.com/hunterhacker/jdom/issues/34 I am confused about where the Saxon interface actually is .... for the moment the transforms are happening through the standard JAXP process. Thanks Rolf On 13/09/2011 4:10 AM, Michael Kay wrote: > >> >> So, I think I will tackle the last remaing chunk of code (transforms), >> and come back to the XPath later.... (Wednesday?) >> > If you're looking at transform, it would be nice to see whether the > interface to Saxon can be improved. At present, I think Saxon is being > presented with a SAXSource and SAXResult so the JDOM source tree is > reconstructed as a Saxon tree. Since Saxon is able to transform JDOM > input directly, this is pretty inefficient. > > Using Saxon to deliver XPath 2.0 access, as an alternative to Jaxen, > would also be quite feasible. > > (Also note: the Javadoc for org.jdom.transform.XSLTransformer is looking > very dated.) > > Michael Kay > Saxonica > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From mike at saxonica.com Tue Sep 13 08:24:34 2011 From: mike at saxonica.com (Michael Kay) Date: Tue, 13 Sep 2011 16:24:34 +0100 Subject: [jdom-interest] XPath and Jaxon In-Reply-To: <4E6F2C2C.3010404@tuis.net> References: <4E6D55BF.8060103@tuis.net> <4E6D9E2B.1010207@uni-jena.de> <4E6DD4D1.3070603@tuis.net> <4E6EBAA8.9090000@tuis.net> <4E6F0FDC.7000303@saxonica.com> <4E6F2C2C.3010404@tuis.net> Message-ID: <4E6F75B2.9030606@saxonica.com> On 13/09/2011 11:10, Rolf wrote: > One of the reasons I have left the transforms to last is because I am > least familiar with them. Essentially, unfamiliar with them... :( I > have used transform to output DOM documents as files/strings, etc, but > that's it. > > For the moment my immediate goal is to 'cover' what we have, so that > we can have a regression baseline. I looked at the XSLTransform class > and figured it largely just leverages the JDOMSource and JDOMResult > classes. I thus have focused on those first. Testing those has been > quite easy by simply 'piping' the results of a JDOMSource transform > back in to a JDOMResult. The guts of that process is using the > XMLOutoutter, SAXOutputter and SAXBuilder anyway which is well covered > too. > Thinking about it again, perhaps the onus is on Saxon to recognize and optimize the case where the input is supplied as a JDOMSource or the output as a JDOMResult. Currently it just treats these as instances of the superclass (SAXSource, SAXResult). Michael Kay Saxonica From jdom at tuis.net Wed Sep 14 07:46:17 2011 From: jdom at tuis.net (Rolf) Date: Wed, 14 Sep 2011 10:46:17 -0400 Subject: [jdom-interest] JDOM2 Update - maven In-Reply-To: References: <4E6EC5CF.5020607@tuis.net> Message-ID: <4E70BE39.802@tuis.net> Hi and thanks, Brad I have just inspected your drop-box repositories (edit, now it's hours later...). I can't 'pull' the changes directly. Those changes have been made against the three git repositories I put together in 2008 as a 'proof of concept'. Those repositories are 'defunct'. There were a number of bugs found in jdom since I put those together, and the plan for JDOM2 stipulated that the jUNit tests get done before the generics... I see you did those changes in late July, it is amazing how fast things seem to change... The setup we now have for JDOM (all versions) is now in github, and the three 'components' (core, test, contrib) are all in the same git repository: https://github.com/hunterhacker/jdom Now that i have spent some time (well, only a few hours) looking at what you have done, and getting more familiar with the maven 'big picture' I have even more concerns than when I started.... The most immediate goal in applying maven is to get the 1.1.2 final build artifacts published on maven-central, and that source branch needs to be as stable as possible. Moving files (and especially renaming/moving directories) would be very, very disruptive to keeping a clean version history. We can be more liberal with those sorts of changes in the JDOM2 branch if we need to. So, for 1.1.2 the goal is to do the minimal changes possible and yet still have a maven artifact at the end. Hmm, it has taken some time to go through this reply, and in the process I have been reading up a little on maven, etc. I have 'formalized' what I think JDOM needs for the maven side of things here: https://github.com/hunterhacker/jdom/wiki/JDOM1.1.2-and-Maven In putting that together I have been hunting around, and there's already two 'groupid' locations for jdom on maven-central. See the wiki page for the links. I have put together a 'feedback' to maven-central hunting down who put those there, and whether it is a problem for putting out 1.1.2.... The more I look in to this the more it looks like it's going to be more of a 'procedural' and 'management' problem than a technical one. I have included Jason on this mail, and have taken the liberty of putting this discussion back on to the jdom-interest list. Read through that wiki-page, tell me if I got anything wrong... perhaps you can help with getting contact details for the 'publisher' of the org.jdom GroupID.... I can't seem to find anything in any of the maven-central files to help though, perhaps i missed something. Thanks Rolf On 14/09/2011 7:21 AM, Brad Cox wrote: > Also need to changed the groupid I choose from Tecnica-PBAC to org.jdom. > Easy to fix. > > On Wed, Sep 14, 2011 at 7:19 AM, Brad Cox > wrote: > > Rolf, I've shared my git clone at > https://www.dropbox.com/home/...xxxxx... You should be able to > pull it from there. > > I've not undone the src/main/java change. Let me know how to proceed. > ... From bcox at virtualschool.edu Wed Sep 14 08:42:47 2011 From: bcox at virtualschool.edu (Brad Cox) Date: Wed, 14 Sep 2011 11:42:47 -0400 Subject: [jdom-interest] JDOM2 Update - maven In-Reply-To: <4E70BE39.802@tuis.net> References: <4E6EC5CF.5020607@tuis.net> <4E70BE39.802@tuis.net> Message-ID: On Wed, Sep 14, 2011 at 10:46 AM, Rolf wrote: > > - The setup we now have for JDOM (all versions) is now in github, and > the three 'components' (core, test, contrib) are all in the same git > repository: https://github.com/**hunterhacker/jdom > > Great! Will pull those tonight (don't have git at work) and retrofit the poms. > > - The most immediate goal in applying maven is to get the 1.1.2 final > build artifacts published on maven-central, and that source branch needs to > be as stable as possible. Moving files (and especially renaming/moving > directories) would be very, very disruptive to keeping a clean version > history. We can be more liberal with those sorts of changes in the JDOM2 > branch if we need to. > > Afraid that's the part I'd be of the least help with. No current experience with central repos, but doubt its hard to learn. But if you can scare up someone who's done it before, might be quicker to just stick with ant and save the build with mvn part for later. The existing 1.1 org.jdom release "SHOULDN'T" be a problem since you're using 1.1.2, but that's the kind of question I'd need to research too. Not been there so far. > > - So, for 1.1.2 the goal is to do the minimal changes possible and yet > still have a maven artifact at the end. > > I'll take a shot at a no-impact pom tonight. -- Cell: 703-594-1883 Blog: http://bradjcox.blogspot.com Web: http://virtualschool.edu Manassas VA 20111 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bcox at virtualschool.edu Wed Sep 14 14:37:37 2011 From: bcox at virtualschool.edu (Brad Cox) Date: Wed, 14 Sep 2011 17:37:37 -0400 Subject: [jdom-interest] JDOM2 Update - maven In-Reply-To: References: <4E6EC5CF.5020607@tuis.net> <4E70BE39.802@tuis.net> Message-ID: Rolf and Jason, I made a quick first pass at the 4 poms for your updated files. They're at the new dropbox address https://www.dropbox.com/home/jdom#:::66844801 I copied them from the .zip file, not git. Couldn't make it work and only now see why. Should be clone, not pull. Hopefully the zip files will do. I didn't change anything except adding the 4 poms, so they should work if you need to move them elsewhere. imac:Dropbox Brad$ git pull https://github.com/hunterhacker/jdom jdom fatal: Not a git repository (or any of the parent directories): .git The poms contain commands to adapt to your source conventions. However at this stage the build products aren't produced in /jdom/build but in /jdom/subcomponent/target which is the maven convention. I could match your build conventions too but that was more than I could tackle tonight. To try it out, type "mvn install" in the root. That works in the subdirs too and builds only that subdir. Let me know if you want to go further with this. I did get some build errors with the ant build; I'm assuming they can be ignored. (?) I don't know ant well enough to diagnose. compile.core: [javac] /Users/Brad/Dropbox/jdom/build.xml:196: warning: 'includeantruntime' was not set, defaulting to build.sysclasspath=last; set to false for repeatable builds [javac] Compiling 62 source files to /Users/Brad/Dropbox/jdom/build/core [javac] /Users/Brad/Dropbox/jdom/build/core/org/jdom2/adapters/JAXPDOMAdapter.java:97: warning: non-varargs call of varargs method with inexact argument type for last parameter; [javac] cast to java.lang.Class for a varargs call [javac] cast to java.lang.Class[] for a non-varargs call and to suppress this warning [javac] factoryClass.getMethod("newInstance", null); [javac] ^ [javac] /Users/Brad/Dropbox/jdom/build/core/org/jdom2/adapters/JAXPDOMAdapter.java:98: warning: non-varargs call of varargs method with inexact argument type for last parameter; and so forth, 4-5 screenfulls. On Wed, Sep 14, 2011 at 11:42 AM, Brad Cox wrote: > On Wed, Sep 14, 2011 at 10:46 AM, Rolf wrote: > >> >> - The setup we now have for JDOM (all versions) is now in github, and >> the three 'components' (core, test, contrib) are all in the same git >> repository: https://github.com/**hunterhacker/jdom >> >> Great! Will pull those tonight (don't have git at work) and retrofit the > poms. > >> >> - The most immediate goal in applying maven is to get the 1.1.2 final >> build artifacts published on maven-central, and that source branch needs to >> be as stable as possible. Moving files (and especially renaming/moving >> directories) would be very, very disruptive to keeping a clean version >> history. We can be more liberal with those sorts of changes in the JDOM2 >> branch if we need to. >> >> Afraid that's the part I'd be of the least help with. No current > experience with central repos, but doubt its hard to learn. But if you can > scare up someone who's done it before, might be quicker to just stick with > ant and save the build with mvn part for later. The existing 1.1 org.jdom > release > "SHOULDN'T" be a problem since you're using 1.1.2, but that's the kind of > question I'd need to research too. Not been there so far. > >> >> - So, for 1.1.2 the goal is to do the minimal changes possible and yet >> still have a maven artifact at the end. >> >> I'll take a shot at a no-impact pom tonight. > -- > Cell: 703-594-1883 > Blog: http://bradjcox.blogspot.com > Web: http://virtualschool.edu > Manassas VA 20111 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdom at tuis.net Wed Sep 14 14:53:46 2011 From: jdom at tuis.net (Rolf) Date: Wed, 14 Sep 2011 17:53:46 -0400 Subject: [jdom-interest] JDOM2 Update - maven In-Reply-To: References: <4E6EC5CF.5020607@tuis.net> <4E70BE39.802@tuis.net> Message-ID: <4E71226A.6050700@tuis.net> Excellent. I have not head back from Sonatype about the 'org.jdom' group id. I will pull the dropbox copy, make sure it works for me, then push the changes up to github. As for the build process, yes, there are warnings. Most of them relate to using a null value to what has become a varargs method in the reflection API. It can be safely ignored, and is one of the things that will be fixed when the junit testing is done. There is another warning in the junit tests because I am directly referencing an internal com.sun.* package to pull in an alternate parser. Will get back to you later on where things are at. Thanks Rolf On 14/09/2011 5:37 PM, Brad Cox wrote: > Rolf and Jason, I made a quick first pass at the 4 poms for your updated > files. They're at the new dropbox address > https://www.dropbox.com/home/jdom#:::66844801 > > I copied them from the .zip file, not git. Couldn't make it work and > only now see why. Should be clone, not pull. > Hopefully the zip files will do. I didn't change anything except adding > the 4 poms, so they should work if you need to move them elsewhere. > ... From jdom at tuis.net Wed Sep 14 21:39:44 2011 From: jdom at tuis.net (Rolf) Date: Thu, 15 Sep 2011 00:39:44 -0400 Subject: [jdom-interest] JDOM2 Update - maven In-Reply-To: <4E71226A.6050700@tuis.net> References: <4E6EC5CF.5020607@tuis.net> <4E70BE39.802@tuis.net> <4E71226A.6050700@tuis.net> Message-ID: <4E718190.1030007@tuis.net> Hi Brad, all. So I have spent hours on this today... (and have spent *no* time working on finishing the jUnit coverage....). The impact of this change is (potentially) farther-reaching than I had hoped, and I am concerned... ... also, I am considering this all from the perspective of JDOM 1.1.x only, so any concerns have no bearing (yet) on JDOM2. There are a number of conflicting goals/requirements here, and there are going to have to be compromises to make it work, so, someone is going to have to make decisions (Jason?). In my analysis I see the following issues (please correct me if I have something wrong): 1. we intend to use http://jdom.org/downloads/ as the 'official' release location of jdom, and maven-central will be 'useful' 2. we intend to keep the existing ant build processes in their entirety for 1.1.2. We do not want to be trying out a new compile and packaging process for it, especially if the final build will likely be done with Java 1.4 or even older (Maven requires 1.5 I believe) (Jason, what did you use to compile 1.1.1?). 3. Maven typically 'hooks' in to the project at a very low level. It often establishes the whole 'personality' of the project before any code is even written. But we only want the 'sweetness' of maven central, not all the 'joys' of dependency management. So, I don't believe what we have at the moment will work, so I have been researching what it is that we can actually do.... and, (at least for 1.1.2), here's what I think we need, and 95% of it is administrative rather than technical... so: 1. leave the ant build (mostly) alone. 2. Register on oss.sonatype.org (I have registered) which is a 'gateway' service for 'feeding' OSS artifacts to maven central (it may have been easier if we were an apache project... ) Go and read: https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide 3. 'reclaim' the org.jdom "Group ID". 4. Create and register GPG signing keys as per sonatype.org instructions 5. modify the ant build (slightly) to build the jars that conform to the oss.sonatype.org requirements: need jdom-javadocs and jdom-sources jars. 6. Consider doing something similar for jdom-contrib (but skil jdom-test) 7. publish the jars on jdom.org From this point on each maven 'release' will be a manual-ish process: 8. Create a 'deploy-only' pom.xml as per the instructions at sonatype 9. push the 'release' to the sonatype staging area using either option 7b or 7c in the sonatype usage guide 10. check on the oss.sonatype.org website, log in, and 'release' the artifacts. 11. Comment on the JIRA created by me today so that the 'maven-central' sync is activated. Form my perspective we can do steps 5, 6, and 7, at any time prior to actually releasing in maven-central. (I only put them there because I think there still need to be some fixes applied to 1.1.2, and I anticipate that steps 1 through 4 will be done before we have all the fixes applied and are 'ready' to release 1.1.2) The rest of the process is just going to be an administrative process, with the usual red tape to negotiate. What it means in the short term is that, as far as I can tell, it is not the 'right thing' to commit Brad's pom.xml files yet: 1. we will only need one pom.xml for 1.1.2 2. 90% of the content in Brad's poms are for building the code, which we will use ant for anyway. 3. 90% of what is required for sonatype.org deployment is not in Brad's poms (and the stuff that's missing is more administrative in nature and I don't know the right answers for them all....) 4. Brad was right the first time, the actual building content is relatively trivial to reproduce if we ever need it. So, I apologize for sounding 'negative' about the maven process, but I am not trying to be.... honestly! Oh, one other option we have is to just simply push JDOM up on to maven-central via a 'third-party' dependency, which is how I think JDOM 1.0 and earlier got on to maven-central before in the 'jdom' group ID, and how jdom 1.1 made it in as part of the 'org.jdom' group ID. See https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central Thanks again Rolf On 14/09/2011 5:53 PM, Rolf wrote: > Excellent. > > I have not head back from Sonatype about the 'org.jdom' group id. > > I will pull the dropbox copy, make sure it works for me, then push the > changes up to github. > > As for the build process, yes, there are warnings. Most of them relate > to using a null value to what has become a varargs method in the > reflection API. It can be safely ignored, and is one of the things that > will be fixed when the junit testing is done. > > There is another warning in the junit tests because I am directly > referencing an internal com.sun.* package to pull in an alternate parser. > > Will get back to you later on where things are at. > > Thanks > > Rolf > > On 14/09/2011 5:37 PM, Brad Cox wrote: >> Rolf and Jason, I made a quick first pass at the 4 poms for your updated >> files. They're at the new dropbox address >> https://www.dropbox.com/home/jdom#:::66844801 >> >> I copied them from the .zip file, not git. Couldn't make it work and >> only now see why. Should be clone, not pull. >> Hopefully the zip files will do. I didn't change anything except adding >> the 4 poms, so they should work if you need to move them elsewhere. >> > ... > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From chrismfwrd at gmail.com Thu Sep 15 00:22:33 2011 From: chrismfwrd at gmail.com (Christian Migowski) Date: Thu, 15 Sep 2011 09:22:33 +0200 Subject: [jdom-interest] JDOM2 Update - maven In-Reply-To: <4E718190.1030007@tuis.net> References: <4E6EC5CF.5020607@tuis.net> <4E70BE39.802@tuis.net> <4E71226A.6050700@tuis.net> <4E718190.1030007@tuis.net> Message-ID: Hi, sorry for jumping in from the side, disregard this mail if the problems are actually settled, it is meant helpful: On Thu, Sep 15, 2011 at 6:39 AM, Rolf wrote: > 1. we intend to use http://jdom.org/downloads/ as the 'official' release > location of jdom, and maven-central will be 'useful' I don't see how this could be affected by building the project with Maven. > 2. we intend to keep the existing ant build processes in their entirety for > 1.1.2. We do not want to be trying out a new compile and packaging process > for it, especially if the final build will likely be done with Java 1.4 or > even older (Maven requires 1.5 I believe) (Jason, what did you use to > compile 1.1.1?). Maven does not use 1.5 per default (try creating and running a new Maven project with a class containing generics) > 3. Maven typically 'hooks' in to the project at a very low level. It often > establishes the whole 'personality' of the project before any code is even > written. But we only want the 'sweetness' of maven central, not all the > 'joys' of dependency management. What exactly are the problems / big changes that come up when building JDOM with Maven? Maven can actually be brought to doing what you want, it is just harder then bending yourself ;) Default directories and names can be changed, multiple locations added, there is a lot possible, it just takes a lot of time to investigate. Since I've done this already for some of our projects I would love to help if this is wanted. The only thing that cannot be changed (I think) is having a local Maven repository populated with all the dependencies required for (building) Jdom - which means at one point in time you have to have internet access during a build so all of this can be downloaded. Thanks for such a great library, it made me recover hope for XML under Java, best regards, christian! > > So, I don't believe what we have at the moment will work, so I have been > researching what it is that we can actually do.... and, (at least for > 1.1.2), here's what I think we need, and 95% of it is administrative rather > than technical... so: > > 1. leave the ant build (mostly) alone. > 2. Register on oss.sonatype.org (I have registered) which is a 'gateway' > service for 'feeding' OSS artifacts to maven central (it may have been > easier if we were an apache project... ) Go and read: > https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide > 3. 'reclaim' the org.jdom "Group ID". > 4. Create and register GPG signing keys as per sonatype.org instructions > 5. modify the ant build (slightly) to build the jars that conform to the > oss.sonatype.org requirements: ?need jdom-javadocs and jdom-sources jars. > 6. Consider doing something similar for jdom-contrib (but skil jdom-test) > 7. publish the jars on jdom.org > > From this point on each maven 'release' will be a manual-ish process: > > 8. Create a 'deploy-only' pom.xml as per the instructions at sonatype > 9. push the 'release' to the sonatype staging area using either option 7b or > 7c in the sonatype usage guide > 10. check on the oss.sonatype.org website, log in, and 'release' the > artifacts. > 11. Comment on the JIRA created by me today so that the 'maven-central' sync > is activated. > > > Form my perspective we can do steps 5, 6, and 7, at any time prior to > actually releasing in maven-central. (I only put them there because I think > there still need to be some fixes applied to 1.1.2, and I anticipate that > steps 1 through 4 will be done before we have all the fixes applied and are > 'ready' to release 1.1.2) > > The rest of the process is just going to be an administrative process, with > the usual red tape to negotiate. > > What it means in the short term is that, as far as I can tell, it is not the > 'right thing' to commit Brad's pom.xml files yet: > 1. we will only need one pom.xml for 1.1.2 > 2. 90% of the content in Brad's poms are for building the code, which we > will use ant for anyway. > 3. 90% of what is required for sonatype.org deployment is not in Brad's poms > (and the stuff that's missing is more administrative in nature and I don't > know the right answers for them all....) > 4. Brad was right the first time, the actual building content is relatively > trivial to reproduce if we ever need it. > > So, I apologize for sounding 'negative' about the maven process, but I am > not trying to be.... honestly! > > Oh, one other option we have is to just simply push JDOM up on to > maven-central via a 'third-party' dependency, which is how I think JDOM 1.0 > and earlier got on to maven-central before in the 'jdom' group ID, and how > jdom 1.1 made it in as part of the 'org.jdom' group ID. See > https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central > > Thanks again > > Rolf > > > On 14/09/2011 5:53 PM, Rolf wrote: >> >> Excellent. >> >> I have not head back from Sonatype about the 'org.jdom' group id. >> >> I will pull the dropbox copy, make sure it works for me, then push the >> changes up to github. >> >> As for the build process, yes, there are warnings. Most of them relate >> to using a null value to what has become a varargs method in the >> reflection API. It can be safely ignored, and is one of the things that >> will be fixed when the junit testing is done. >> >> There is another warning in the junit tests because I am directly >> referencing an internal com.sun.* package to pull in an alternate parser. >> >> Will get back to you later on where things are at. >> >> Thanks >> >> Rolf >> >> On 14/09/2011 5:37 PM, Brad Cox wrote: >>> >>> Rolf and Jason, I made a quick first pass at the 4 poms for your updated >>> files. They're at the new dropbox address >>> https://www.dropbox.com/home/jdom#:::66844801 >>> >>> I copied them from the .zip file, not git. Couldn't make it work and >>> only now see why. Should be clone, not pull. >>> Hopefully the zip files will do. I didn't change anything except adding >>> the 4 poms, so they should work if you need to move them elsewhere. >>> >> ... >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Thu Sep 15 03:13:28 2011 From: jdom at tuis.net (Rolf) Date: Thu, 15 Sep 2011 06:13:28 -0400 Subject: [jdom-interest] JDOM2 Update - maven In-Reply-To: References: <4E6EC5CF.5020607@tuis.net> <4E70BE39.802@tuis.net> <4E71226A.6050700@tuis.net> <4E718190.1030007@tuis.net> Message-ID: <4E71CFC8.9000901@tuis.net> Hi Christian No problem about jumping in at all! It is probably worth recapping the reasoning anyway, so here goes. JDOM2 is where all the exciting and (relatively) 'sexy' changes are going to happen. JDOM 1.1.2 on the other hand must follow on the tradition that JDOM has had so far of reliability, predictability, compatability, etc. There are some bugs that need fixing in the 1.1.2 stream, and we expect that code to be used for years to come. The people who use it will want to have a 'no issues' drop in replacement for their 1.1.1 jar. We do not want to 'destabilize' the 1.1.2 code in any way. The current JDOM build process does some 'odd' things: 1. It uses ant filters to whole-sale copy the *.java files in to a separate location, and there may be some changes made to that code in the process (small changes, admittedly, and I don't know exactly where...) 2. It uses some tricks to make a custom manifest file in the .jar files 3. It needs to build the code to be compatible with Java 1.2 (I am hoping Jason will chime in with exactly how we can (still) do that in the best way possible. These things are 'complicated' and would require us to be 'experts' in *both* JDOM *and* Maven to 'convert' 1.1.2 to Maven and be confident in the full compatibility of the result. At the moment I don't believe there is a single person who is qualified to the required degree... (in both toos) ;-) In addition, we don't want to spend time 'fixing' or 'investigating' issues in 1.1.2. We don't want to have to worry about it in any way. Our focus should be on JDOM2. The simplest thing is to just do what has always been done and is tried and true.... but still keep maven users happy by having jdom-1.1.2.jar in maven central. Speaking of which I have had some feedback from sonatype.... I will forward it to the list for 'the record'. It seems like everything is 'on track' on the administration side. Rolf On 15/09/2011 3:22 AM, Christian Migowski wrote: > Hi, > > sorry for jumping in from the side, disregard this mail if the > problems are actually settled, it is meant helpful: > > On Thu, Sep 15, 2011 at 6:39 AM, Rolf wrote: >> 1. we intend to use http://jdom.org/downloads/ as the 'official' release >> location of jdom, and maven-central will be 'useful' > > I don't see how this could be affected by building the project with Maven. > >> 2. we intend to keep the existing ant build processes in their entirety for >> 1.1.2. We do not want to be trying out a new compile and packaging process >> for it, especially if the final build will likely be done with Java 1.4 or >> even older (Maven requires 1.5 I believe) (Jason, what did you use to >> compile 1.1.1?). > > Maven does not use 1.5 per default (try creating and running a new > Maven project with a class containing generics) > >> 3. Maven typically 'hooks' in to the project at a very low level. It often >> establishes the whole 'personality' of the project before any code is even >> written. But we only want the 'sweetness' of maven central, not all the >> 'joys' of dependency management. > > What exactly are the problems / big changes that come up when building > JDOM with Maven? Maven can actually be brought to doing what you want, > it is just harder then bending yourself ;) Default directories and > names can be changed, multiple locations added, there is a lot > possible, it just takes a lot of time to investigate. Since I've done > this already for some of our projects I would love to help if this is > wanted. The only thing that cannot be changed (I think) is having a > local Maven repository populated with all the dependencies required > for (building) Jdom - which means at one point in time you have to > have internet access during a build so all of this can be downloaded. > > Thanks for such a great library, it made me recover hope for XML under Java, > best regards, > christian! > >> >> So, I don't believe what we have at the moment will work, so I have been >> researching what it is that we can actually do.... and, (at least for >> 1.1.2), here's what I think we need, and 95% of it is administrative rather >> than technical... so: >> >> 1. leave the ant build (mostly) alone. >> 2. Register on oss.sonatype.org (I have registered) which is a 'gateway' >> service for 'feeding' OSS artifacts to maven central (it may have been >> easier if we were an apache project... ) Go and read: >> https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide >> 3. 'reclaim' the org.jdom "Group ID". >> 4. Create and register GPG signing keys as per sonatype.org instructions >> 5. modify the ant build (slightly) to build the jars that conform to the >> oss.sonatype.org requirements: need jdom-javadocs and jdom-sources jars. >> 6. Consider doing something similar for jdom-contrib (but skil jdom-test) >> 7. publish the jars on jdom.org >> >> From this point on each maven 'release' will be a manual-ish process: >> >> 8. Create a 'deploy-only' pom.xml as per the instructions at sonatype >> 9. push the 'release' to the sonatype staging area using either option 7b or >> 7c in the sonatype usage guide >> 10. check on the oss.sonatype.org website, log in, and 'release' the >> artifacts. >> 11. Comment on the JIRA created by me today so that the 'maven-central' sync >> is activated. >> >> >> Form my perspective we can do steps 5, 6, and 7, at any time prior to >> actually releasing in maven-central. (I only put them there because I think >> there still need to be some fixes applied to 1.1.2, and I anticipate that >> steps 1 through 4 will be done before we have all the fixes applied and are >> 'ready' to release 1.1.2) >> >> The rest of the process is just going to be an administrative process, with >> the usual red tape to negotiate. >> >> What it means in the short term is that, as far as I can tell, it is not the >> 'right thing' to commit Brad's pom.xml files yet: >> 1. we will only need one pom.xml for 1.1.2 >> 2. 90% of the content in Brad's poms are for building the code, which we >> will use ant for anyway. >> 3. 90% of what is required for sonatype.org deployment is not in Brad's poms >> (and the stuff that's missing is more administrative in nature and I don't >> know the right answers for them all....) >> 4. Brad was right the first time, the actual building content is relatively >> trivial to reproduce if we ever need it. >> >> So, I apologize for sounding 'negative' about the maven process, but I am >> not trying to be.... honestly! >> >> Oh, one other option we have is to just simply push JDOM up on to >> maven-central via a 'third-party' dependency, which is how I think JDOM 1.0 >> and earlier got on to maven-central before in the 'jdom' group ID, and how >> jdom 1.1 made it in as part of the 'org.jdom' group ID. See >> https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+Maven+Central >> >> Thanks again >> >> Rolf >> >> >> On 14/09/2011 5:53 PM, Rolf wrote: >>> >>> Excellent. >>> >>> I have not head back from Sonatype about the 'org.jdom' group id. >>> >>> I will pull the dropbox copy, make sure it works for me, then push the >>> changes up to github. >>> >>> As for the build process, yes, there are warnings. Most of them relate >>> to using a null value to what has become a varargs method in the >>> reflection API. It can be safely ignored, and is one of the things that >>> will be fixed when the junit testing is done. >>> >>> There is another warning in the junit tests because I am directly >>> referencing an internal com.sun.* package to pull in an alternate parser. >>> >>> Will get back to you later on where things are at. >>> >>> Thanks >>> >>> Rolf >>> >>> On 14/09/2011 5:37 PM, Brad Cox wrote: >>>> >>>> Rolf and Jason, I made a quick first pass at the 4 poms for your updated >>>> files. They're at the new dropbox address >>>> https://www.dropbox.com/home/jdom#:::66844801 >>>> >>>> I copied them from the .zip file, not git. Couldn't make it work and >>>> only now see why. Should be clone, not pull. >>>> Hopefully the zip files will do. I didn't change anything except adding >>>> the 4 poms, so they should work if you need to move them elsewhere. >>>> >>> ... >>> _______________________________________________ >>> To control your jdom-interest membership: >>> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >>> >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> > From jdom at tuis.net Thu Sep 15 03:16:03 2011 From: jdom at tuis.net (Rolf) Date: Thu, 15 Sep 2011 06:16:03 -0400 Subject: [jdom-interest] Maven - Re: question: Publisher of groups 'jdom' and 'org.jdom' In-Reply-To: <9118AB8246D64A3FB3FC3B4029E92493@sonatype.com> References: <9118AB8246D64A3FB3FC3B4029E92493@sonatype.com> Message-ID: <4E71D063.8070108@tuis.net> The following is a response from Sonatype =========================================== Hi Rolf, The existing jdom artifacts were published to maven central via outdated Codehaus MAVENUPLOAD service [1][2]. The MAVENUPLOAD service is already outdated and the last modified date of these files are either in 2007 or 2008, so I believe there is no one actively deploying any more jdom artifacts. Since we know you are one of the jdom maintainers, as long as you start to use OSSRH service [3], we can make sure no one else can deploy jdom to central. Regarding cleaning up existing jdom artifacts, sorry we can not do that. It's because they might be used a lot by maven users all around the world. If we delete/change any of these files, people's builds will break. We can fix/rebuild maven-metadata though, so the latest version will be a correct and official one published by you. We can also put a relocation POM under groupId jdom, so people's downloads can be relocated to org.jdom. [1] http://jira.codehaus.org/browse/MAVENUPLOAD-1968 [2] http://jira.codehaus.org/browse/MAVENUPLOAD-78 [3] https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide Thanks, Juven On Wednesday, September 14, 2011 at 10:21 PM, Private feedback from Rolf Lear wrote: > Rolf Lear (jdom at tuis.net) gave private feedback from > http://search.maven.org/ . > > Publisher of groups 'jdom' and 'org.jdom' > > Hi > > I am (one of) the maintainers for the JDOM Project. > > We are in the process of ensuring that our builds will be published on > maven-central. The demand is so 'strong' that it appears that over > time someone (or more than one) has already established the > 'co-ordinates' for the JDOM artifacts in maven central. > > By my rekoning there are two locations which appear to be significant: > http://search.maven.org/#browse%7C718... > > http://search.maven.org/#browse%7C100... > > > How can I go about contacting the person/people who published those > artifacts? > Is there a procedure for cleaning up these two locations in to (I > presume) just the org.jdom GroupID? > > We are preparing a 1.1.2 release in the next month or so, and it would > be great if we can get it available 'correctly' and 'officially' in > maven-central. > > Thanks > > Rolf > From jdom at tuis.net Thu Sep 15 07:32:34 2011 From: jdom at tuis.net (Rolf Lear) Date: Thu, 15 Sep 2011 10:32:34 -0400 Subject: [jdom-interest] Maven - Re: question: Publisher of groups 'jdom' and 'org.jdom' In-Reply-To: <4E71D063.8070108@tuis.net> References: <9118AB8246D64A3FB3FC3B4029E92493@sonatype.com> <4E71D063.8070108@tuis.net> Message-ID: Another update: The following is the 'issue' open (now resolved) at sonatype. https://issues.sonatype.org/browse/OSSRH-2219 This issue has now been 'resolved' but not yet 'closed'. What this means is that sonatype have created a set of 'repositories' in which we can deploy JDOM artifacts. When we have got something to release, and when that something has been staged, and 'released' in sonatype (and we are happy with the way it will look), we can then comment on the above 'issue' to that effect. At that point sonatype will activate the synchronization link to maven-central, and out changes will be 'pushed' there. Bottom line is that in my previous mail I listed 10 steps to get the maven 'right', well, steps 1 through 3 are now done.... Rolf In their words: ================= Configuration has been prepared, now you can: * Deploy snapshot artifacts into repository https://oss.sonatype.org/content/repositories/snapshots * Deploy release artifacts into the staging repository https://oss.sonatype.org/service/local/staging/deploy/maven2 * Promote staged artifacts into repository 'Releases' * Download snapshot and release artifacts from group https://oss.sonatype.org/content/groups/public * Download snapshot, release and staged artifacts from staging group https://oss.sonatype.org/content/groups/staging ================= On Thu, 15 Sep 2011 06:16:03 -0400, Rolf wrote: > The following is a response from Sonatype > > =========================================== > > Hi Rolf, > > The existing jdom artifacts were published to maven central via outdated > Codehaus MAVENUPLOAD service [1][2]. > > The MAVENUPLOAD service is already outdated and the last modified date > of these files are either in 2007 or 2008, so I believe there is no one > actively deploying any more jdom artifacts. Since we know you are one of > the jdom maintainers, as long as you start to use OSSRH service [3], we > can make sure no one else can deploy jdom to central. > > Regarding cleaning up existing jdom artifacts, sorry we can not do that. > It's because they might be used a lot by maven users all around the > world. If we delete/change any of these files, people's builds will > break. We can fix/rebuild maven-metadata though, so the latest version > will be a correct and official one published by you. We can also put a > relocation POM under groupId jdom, so people's downloads can be > relocated to org.jdom. > > [1] http://jira.codehaus.org/browse/MAVENUPLOAD-1968 > [2] http://jira.codehaus.org/browse/MAVENUPLOAD-78 > [3] > https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide > > Thanks, > Juven > > On Wednesday, September 14, 2011 at 10:21 PM, Private feedback from Rolf > Lear wrote: > >> Rolf Lear (jdom at tuis.net) gave private feedback from >> http://search.maven.org/ . >> >> Publisher of groups 'jdom' and 'org.jdom' >> >> Hi >> >> I am (one of) the maintainers for the JDOM Project. >> >> We are in the process of ensuring that our builds will be published on >> maven-central. The demand is so 'strong' that it appears that over >> time someone (or more than one) has already established the >> 'co-ordinates' for the JDOM artifacts in maven central. >> >> By my rekoning there are two locations which appear to be significant: >> http://search.maven.org/#browse%7C718... >> >> http://search.maven.org/#browse%7C100... >> >> >> How can I go about contacting the person/people who published those >> artifacts? >> Is there a procedure for cleaning up these two locations in to (I >> presume) just the org.jdom GroupID? >> >> We are preparing a 1.1.2 release in the next month or so, and it would >> be great if we can get it available 'correctly' and 'officially' in >> maven-central. >> >> Thanks >> >> Rolf >> > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Sun Sep 18 20:09:34 2011 From: jdom at tuis.net (Rolf) Date: Sun, 18 Sep 2011 23:09:34 -0400 Subject: [jdom-interest] codehaus password Message-ID: <4E76B26E.6010508@tuis.net> From jdom at tuis.net Sun Sep 18 20:15:50 2011 From: jdom at tuis.net (Rolf) Date: Sun, 18 Sep 2011 23:15:50 -0400 Subject: [jdom-interest] codehaus password In-Reply-To: <4E76B26E.6010508@tuis.net> References: <4E76B26E.6010508@tuis.net> Message-ID: <4E76B3E6.1040006@tuis.net> Heh... well, at least I know the list works ... right? Rolf On 18/09/2011 11:09 PM, Rolf wrote: > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com > From jdom at tuis.net Sun Sep 18 20:58:15 2011 From: jdom at tuis.net (Rolf) Date: Sun, 18 Sep 2011 23:58:15 -0400 Subject: [jdom-interest] JDOM2 Update. Message-ID: <4E76BDD7.7050505@tuis.net> Hi all. The JUnit test coverage is coming to an end. Currently, for all of JDOM, the numbers are at 91% line coverage, and 92% code-path coverage. There have been a number of issues that have come up, with the largest being XPath. There are/were a number of bugs in that code, and there are some bugs in the Jaxen code's JDOM plugin, which I cant easily fix. The entire org.jdom2.xpath.XPath API is somewhat broken, and I expect it all to be revised. Further, I expect for JDOM2 that the jaxen 'plugin' will be moved from Jaxen to JDOM as well. As a result of the XPath mess, and also because of a single issue w.r.t the processing of multiple Text-based contents in TRIM_FULL_WHITE mode (issue #31), there are some failing JUnit tests (2 fail, 5 error). My current plan is to work on the XPath code. I have already started work on a replacement 'Navigator' implementation that will be the official one for JDOM2, but, I am looking for some input on the best way to solve the API issues. I will put together a separate e-mail for that. When I am done with that I am going to work through the issues that have been raised so far, and figure out what should be back-ported to 1.1.2. Perhaps we can even get a 'snapshot' of 1.1.2 on to maven. I think now would also be a good time to add headers and do a little tidying to the test code that's been added. What this means is that I expect by this week's end, that there will be a well-covered, fixed, and clean set of code from which to start working on the generics and other treats. Rolf From jdom at tuis.net Sun Sep 18 21:23:02 2011 From: jdom at tuis.net (Rolf) Date: Mon, 19 Sep 2011 00:23:02 -0400 Subject: [jdom-interest] JDOM and XPath API Message-ID: <4E76C3A6.50009@tuis.net> Hi All. The XPath code needs some work on the API side of things. The current stat is that there is the class org.jdom2.xpath.XPath. This class performs two basic roles, it is the abstract base for any implemenations that provide XPath processing, and it is also a factory (of sorts) for setting the engine that will service XPaths. The problem is that the Factory-type method is not very useful, for the following reasons: 1. The 'default' factory is not accessible by name (because JaxenXPath is not public). 2. Changing the 'factory' class is system-wide (a static), and means that your entire Java JVM needs to have the same active factory, The bigger problem is that there is no good way to fix this problem without a significant change to the API. What should that change be? I envisage a fix that introduces a classic Factory pattern. This will require removing the factory type methods from the XPath class, to the XPathFactory class. Further, with that change, the XPath class can easily become an interface... which may improve the flexibility of some things. The XPathFactory class can have the same newInstance(), selectNodes() And selectSingleNode() methods which will in turn use a shortcut to the defaultFactory(). But, it can also be used to allow for different implementations of the factory. For reference (perhaps even performance), we should maybe put together an implementation that uses javax.xml.xpath to get the details out of a DOM implementation.... Any comments, concerns? Similarly, the Jaxen engine for XPath has code for 'navigatin' a JDOM document. THis code references org.jdom classes, and we need it to access org.jdom2. This navigation functionality should be re-implemented on the JDOM2 side instead. Rolf From jdom at tuis.net Sun Sep 18 21:38:16 2011 From: jdom at tuis.net (Rolf) Date: Mon, 19 Sep 2011 00:38:16 -0400 Subject: [jdom-interest] Adapters Message-ID: <4E76C738.8050506@tuis.net> org.jdom2.adapters can be stripped of a lot of stuff. For a start, the API has basically two methods, createDocument() which creates an empty org.w3.dom Document class based on the appropriate adaptor. The getDocument() methods are a simple wrapper for creating a DOM Document from a file or input source. In reality, only the createDocument() class is used, and, further, the only actual Adapter that is needed is the JAXPDOMAdapter The rest can all be stripped. Any issues? Rolf From mike at saxonica.com Mon Sep 19 01:28:30 2011 From: mike at saxonica.com (Michael Kay) Date: Mon, 19 Sep 2011 09:28:30 +0100 Subject: [jdom-interest] JDOM and XPath API In-Reply-To: <4E76C3A6.50009@tuis.net> References: <4E76C3A6.50009@tuis.net> Message-ID: <4E76FD2E.6090008@saxonica.com> > Further, with that change, the XPath class can easily become an > interface... which may improve the flexibility of some things. > > The XPathFactory class can have the same newInstance(), selectNodes() > And selectSingleNode() methods which will in turn use a shortcut to > the defaultFactory(). But, it can also be used to allow for different > implementations of the factory. > The methods selectNodes() and selectSingleNode() are very XPath-1.0 oriented. If there's going to be an API change at this stage of the game, it would really make sense to anticipate XPath 2.0. Unfortunately that's potentially quite complex, for example how do you handle an XPath expression that returns a sequence of dates? For two attempts to solve this problem, you can look at the XQJ API and Saxon's s9api API. Michael Kay From jdom at tuis.net Mon Sep 19 10:47:58 2011 From: jdom at tuis.net (Rolf Lear) Date: Mon, 19 Sep 2011 13:47:58 -0400 Subject: [jdom-interest] =?utf-8?q?Preparing_JDOM_1=2E1=2E2_=3F?= In-Reply-To: <4E5F1679.6010403@tuis.net> References: <2b5387045b45787a1ae51a31006c370f@tuis.net> <903C57B2-8752-43B5-914C-7EBEF19B17F5@servlets.com> <4E5F1679.6010403@tuis.net> Message-ID: Hi All. The junit testing for JDOM2 is essentially complete in terms of regression testing, and there have been a number of issues found as a result of this testing. I have gone through the issues and labeled those issues I think should be fixed in 1.1.2 with a yellow 'backport 1.1.2'. I have also applied some of the fixes already, and I have labeled those fixes with a green 'backport 1.1.2 done'. Please inspect the lists at https://github.com/hunterhacker/jdom/issues and drop a note if you think there are issues that are mislabeled... i.e. you think there are unlabeled issues that should be backported, or labeled issues you think should not be backported. I am hoping to get this list somewhat finalized and then finish the backport. At that point it would make sense to put out a 'beta' version of jdom-1.1.2 using the new github code base, to ensure that there are no unforseen build problems. People should be able to do a drop-in of the 1.1.2 beta with their current 1.1.1 jar. We can put the maven repository to use for a 'snapshot' build, and can use that infrastructure to manage the artifacts. It will also allow us to set up the correct maven procedures. That way we can have all issues ironed out when 1.1.2 is fully released. Rolf On Thu, 01 Sep 2011 01:22:01 -0400, Rolf wrote: > Hi all. > > I have set up the process/infrastructure for JDOM 1.1.2 > > I initially set up the github branches incorrectly. I used 'branch' > structures to indicate previous JDOM releases, when I should have used > plain tags. So, I have removed the branch called jdom-1.1.1 and instead > created a tag called jdom-1.1.1 (I also moved it from the revision it > was on to the actual revision used for jdom-1.1.1). > > I have now created a branch jdom-1.x which will be used as the > development branch for future pre-JDOM2 development/fixes. > > The process for the above changes can be read up on at: > https://github.com/hunterhacker/jdom/wiki/Source-Branches-and-JDOM2 > (see the update near the bottom...). > > I have gone through the issues (open and closed) in github and I have > 'labelled' those issues I believe are good for backporting to jdom-1.1.2 > > If any new issues arise, or if anyone thinks there are issues on that > list which should or should not be backported to 1.1.2 then please speak > up. I intend to start working on the backport quite soon (it should be > really quick and easy). The bigger problem is that I have not yet > finished the junit testing, so there may be some more issues that arise. > I expec that by the end of next week the junit testing will be > sufficient for JDOM2 work. > > Rolf > > On 30/08/2011 6:15 PM, Jason Hunter wrote: >> On Aug 25, 2011, at 11:50 AM, Rolf Lear wrote: >> >>> Hi all >>> >>> Jason, the way I understand it is that we are intending a 1.1.2 release. >>> There are some issues in GitHub targeting that release. >>> >>> I think it is worth discussing some fixes for a JDOM 1.1.2 release. >>> >>> Currently the list of 1.1.2 Milestone issues is: >>> #1 Namespace for default attributes from XMLSchema >>> https://github.com/hunterhacker/jdom/issues/1 >>> #3 Should have a build in Maven Central >>> https://github.com/hunterhacker/jdom/issues/3 >>> >>> >>> I am unsure of how much priority should be put on 1.1.2 items. On the >>> one >>> hand, I think that these issues are high priority, and should be >>> addressed. >>> On the other hand, I find it hard to figure out where to draw the line. >> >> My general feeling is we should do a 1.1.2 with any bug fixes that are >> low-risk, don't introduce any compatibility issues, and will be coded up >> soon. >> >>> Also, the Maven issue is probably quite disruptive in terms of code >>> impact.... and, I feel it would be a lot of effort to 'mavenize' both >>> 1.1.2 >>> and 2.0... I see that issue (#3) as being a 2.0 milestone, not 1.1.2 >> >> Why the code impact? I wasn't suggesting we use Maven, just put builds >> out there so others who use Maven can fetch JDOM builds. Looks like >> others have been doing this for us up til now: >> >> http://mvnrepository.com/artifact/jdom/jdom >> >>> There are some other issues already filed which could be part of 1.1.2, >>> but no-one has properly addressed. Things like >>> https://github.com/hunterhacker/jdom/issues/9 - BaseURI not output. >>> >>> Also, what I am finding is that as I go through adding JUnit tests I >>> have >>> encountered a number of small issues. Each of them is trivial to fix (so >>> far, anyway), but, when taken together, there are enough to warrant a >>> 1.1.2 >>> release. Further, I am sure that there will be even more as I cover >>> more of >>> the JDOM code. I have been itemizing these small issues in GitHub as I >>> go >>> so that I can 'document' what has changed, but the same items can be >>> used >>> to fix 1.1.2. >>> >>> I have been concentrating on the JDOM2 coverage, but, I think it would >>> make sense to also get a 1.1.2 branch going, and clearing up some of the >>> 1.1.2 issues. >>> >>> That is, assuming we are planning a 1.1.2 release.... we are, aren't we? >> >> It seems like a good idea, targeted to people who are conservative. >> >>> >>> I have inspected the branch on GitHub labeled as JDOM-1.1.1. There is >>> one >>> difference between that branch, and the actual code released as 1.1.1, >>> and >>> that is commit >>> https://github.com/hunterhacker/jdom/commit/ea30b1e2b614f4b7d49de8a95af71fe3fb52ae2b >>> >>> It seems to me that I can move the 1.1.1 branch back up one commit, and >>> then branch the 1.1.2 from where the 1.1.1 was. it seems simple in my >>> head, >>> but I will have to research the best way to do it in my head. >> >> Cool. Please when you're done add to the wiki how you did it, since >> it'll help all us git-noobs learn. BTW, I have git-guru friends if we >> need to ask them. >> >>> Once we get a 1.1.2 branch going it should be easy for me to apply any >>> fixes to both 2.0 and 1.1.2 (if we agree that they should be >>> back-ported to >>> 1.1.2). >>> >>> Anyway, the way I see it is that a 1.1.2 release should be 'planned' ( - >>> or completely dismissed and just roll things in to 2.0.0). >> >> I feel like there would be demand for a 1.1.2 that's basically a >> risk-free drop-in upgrade for people on 1.1.1 that includes some fixes. >> >> -jh- >> > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From thomas.scheffler at uni-jena.de Thu Sep 29 02:26:52 2011 From: thomas.scheffler at uni-jena.de (Thomas Scheffler) Date: Thu, 29 Sep 2011 11:26:52 +0200 Subject: [jdom-interest] Bug in Text.append(String) In-Reply-To: References: Message-ID: <4E8439DC.8080900@uni-jena.de> Am 29.09.2011 09:30, schrieb Jack Punt: > This does the wrong thing when str = EMPTY_STRING > (dubious: should be str.equals("") since new String() != "") > but the real bug is that value=str; clears the old value instead of > appending... Hi, what about (str.length() == 0) ? regards Thomas