From jdom at tuis.net Tue Jun 5 12:03:18 2012 From: jdom at tuis.net (Rolf Lear) Date: Tue, 05 Jun 2012 15:03:18 -0400 Subject: [jdom-interest] Preparing next release In-Reply-To: <4FC6ABF7.4070102@tuis.net> References: <150dd369ca87ab8f8b712f7d507144ae@tuis.net> <4FC6ABF7.4070102@tuis.net> Message-ID: hello everyone (again). After some 'study', and some discussion on the maven-user's mailing list, I have come to the conclusion that the maven predicament is best solved using a 'legacy' type approach. In summary, I plan to re-release jdom 1.1.3 on maven-central as the new artifact 'jdom-legacy' version 1.1.3. The reasons are as follows: 1. For non-maven JDOM users it makes no difference (there is no impact for non-maven users). 2. For most maven users there is no impact (they can just choose which version of the 'jdom' artifact they want to use). 3. For those maven users needing both 1.x and 2.x they can use 'jdom' artifact for 2.x, and the 'jdom-legacy' artifact for 1.x 4. This 'solution' does not 'burn any (more) bridges'.... 5. It makes the maven processes independent of JDOM releases. Future versions of jdom 2.x will continue to be released to the jdom artifact. Rolf On Wed, 30 May 2012 19:23:35 -0400, Rolf Lear wrote: > Hi again. > > Just to let you know that while I was originally going to release 2.0.2 > before month-end, I have instead decided to release it probably some > time next week. > > In the interim I am learning a bunch about maven, and I am tracking down > some additional input to how to resolve the maven problems. It seems > that learning maven to the extent I need is not going to be a 1-day > exercise. > > So, expect 2.0.2 before the 9th of June. > > Rolf > > On 28/05/2012 7:47 AM, Rolf Lear wrote: >> >> Hi All. >> >> I am getting ready to push out version 2.0.2 of the JDOM 2.x stream. >> >> Currently in this release is the fix for issue #81 (resetting live >> FitlerLists after a remove()). >> >> This is the only known bug in JDOM 2.x and a 'hotfix' has been available >> for a few weeks. It is time to push out the official release. >> >> >> Additionally, there are issues/concerns regarding the maven artifiacts. >> The core issue is that currently it is not possible to 'require' both >> JDOM >> 1.x and 2.x in your maven project. There appears to be only one solution >> to >> this issue and that is to have different 'artifacts' for JDOM 1 and JDOM >> 2. >> Obviously (in hindsight) it should have been done this way originally, >> but >> there was simply not enough 'expert' feedback/input/assistance when the >> decisions were being made, and this mistake is now something that just >> has >> to be lived with. >> >> As a result, it appears necessary to deploy JDOM 2.0.2 to the maven >> artifact 'jdom2' (previous versions were deployed to 'jdom'). >> >> While this change will make it possible to include both JDOM 1.x and 2.x >> in your maven projects it will also introduce a number of irritating >> side-effects: >> >> For 'regular' users, note: >> 1. previous versions of JDOM 2.x were called jdom-2.0.0.jar and >> jdom-2.0.1.jar. This new version will be called jdom2-2.0.2.jar, and the >> 'zip' file will be called jdom2-2.0.2.zip >> >> For maven users, note: >> >> 1. if you have already incorporated JDOM 2.x in your project you should >> update your dependency to be for artifact jdom2, not jdom >> 2. ensure any maven project you require that also depends on JDOM aware >> of >> this problem... because, if that required project 'upgrades' to the jdom >> artifact version 2.0.1 (instead of jdom2) then you will get two different >> versions of jdom 2.x in your classpath, and there is no telling what will >> result..... >> >> >> So, it is quite possible that by 'solving' the issue relating to >> requiring >> both JDOM 1.x and 2.x, that we will instead be introducing even worse >> problems, but I have been assured that this is the 'only' way to move >> forward from here. >> >> If anyone has comments, concerns, suggestions, I am all ears. >> >> Rolf >> >> _______________________________________________ >> To control your jdom-interest membership: >> http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com >> From jdom at tuis.net Thu Jun 7 16:06:31 2012 From: jdom at tuis.net (Rolf Lear) Date: Thu, 07 Jun 2012 19:06:31 -0400 Subject: [jdom-interest] Example of LocatedElement In-Reply-To: References: Message-ID: <4FD133F7.4040402@tuis.net> Hi Jose. If you want to locate just the first error then you should just check the JDOMException returned when parsing. If you want to locate all the errors/warnings, then you should create an ErrorHandler instance, and override the respective methods, and get the location of the parsing error when the respective error-handler method is called, and make sure you do not throw an excepion from the ErrorHandler method. If you just want to get the location of all the content (not just the errors), then you should use the ortg.jdom2.located.LocatedJDOMFactory for your SAXBuilder and all the resulting content will implement the org.jdom2.located.Located interface (with a getLine() and getColumn() method). If you want to have both LocatedElement results as well as trapping each error, you may want to experiment with using both an ErrorHandler and LocatedJDOMFactory for the SAXBuilder. As for examples, well, the test-cases for locatedJDOMFactory would be a logical place I guess, but since the functionality is new in JDOM 2, I don't think that there are many examples 'in the wild': https://github.com/hunterhacker/jdom/blob/master/test/src/java/org/jdom2/test/cases/located/TestLocatedJDOMFactory.java#L51 For examples of error handlers.... the test harness will not help much, but this should help: http://www.saxproject.org/apidoc/org/xml/sax/ErrorHandler.html and http://www.jdom.org/docs/apidocs/org/jdom2/input/SAXBuilder.html#getErrorHandler%28%29 Rolf On 07/06/2012 6:50 PM, JOSE L MARTINEZ-AVIAL wrote: > Hello, > Has somebody an example of how LocatedElement can be used? I use Jdom > to parse an XML using SAXBuilder, and I'd like to pinpoint to the user > the location of an error in the file, but so far I haven't seen any > example of how to get the LocatedElement of an element. > > Thanks > > JL > > > _______________________________________________ > To control your jdom-interest membership: > http://www.jdom.org/mailman/options/jdom-interest/youraddr at yourhost.com From jdom at tuis.net Mon Jun 11 04:39:48 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 11 Jun 2012 07:39:48 -0400 Subject: [jdom-interest] JDOM 2.0.2 is released Message-ID: <00726e8629e99813e584de035d3618b5@tuis.net> Hi all! JDOM 2.0.2 is out and available at http://jdom.org/downloads/index.html It is also available on maven-central as GroupID org.jdom, ArtifactID jdom, and Version 2.0.2. This release fixes the single issue https://github.com/hunterhacker/jdom/issues/81 - content 'removed' from an Element would cause corruption on any active 'live' sub-lists of the Element. In addition, there is an improved error message in the XPath code, as well as some minor JavaDoc clarifications. ==== For details on all the new features available in JDOM 2.x please see the wiki page: https://github.com/hunterhacker/jdom/wiki/JDOM2-Features For a 'Primer' on getting started with JDOM 2.x, some basic concepts, and examples on how to accomplish the most common tasks in JDOM, see: https://github.com/hunterhacker/jdom/wiki/JDOM2-A-Primer For insights on what issues to expect when changing from JDOM 1.x to 2.x have a look at the 'Migration Guide' here: https://github.com/hunterhacker/jdom/wiki/JDOM2-Migration-Issues The JavaDoc is available in the release, as well as at: http://jdom.org/docs/apidocs/index.html As always, if you have any comments, suggestions, concerns, please speak up! Happy Coding Rolf From jdom at tuis.net Mon Jun 11 05:13:06 2012 From: jdom at tuis.net (Rolf Lear) Date: Mon, 11 Jun 2012 08:13:06 -0400 Subject: [jdom-interest] JDOM artifact 'jdom-legacy' in maven Message-ID: <5c99d8dd41a95a718acafd2c5d867296@tuis.net> Hi All. I am pleased to announce the new JDOM artifact 'jdom-legacy' in maven. This artifact is introduced to make it possible for maven users to have both JDOM 1.x and 2.x version in their project at the same time. The Problem: ============ There are three types of JDOM users: - non-maven users - maven users who have a 'simple' dependency chain on JDOM (only require one JDOM version) - maven users with a complicated dependency chain on JDOM (require both 1.x and 2.x JDOM versions). Non-maven users are completely unaffected by any version/artifact problems, and this is a non-issue for them. Simple maven dependencies are also easy to handle: maven users (like always) simply choose which version of the jdom artifact to use (1.1.3, 2.0.2, etc.), and these maven users have not been affected by any issues. The only problem has been for maven users with complicated dependency requirements. The typical condition is for the maven user whio is upgrading their code to use JDOM 2.x, but has a 'transitive dependency' on JDOM 1.x. This happens, for example, when your code uses JDOM 2.x, but you depend on some other maven artifact which in turn depends on JDOM 1.x. In this condition, maven will choose to include just the 2.x version of JDOM, and the program will fail at run-time because the third-party code will not be able to find it's JDOM classes. The Solution: ============= The solution is to introduce a second maven artifact for JDOM. Maven can then be instructed to pull the second JDOM version of code from the second artifact. There are effectively two options: either introduce a new artifact for JDOM 2.x code, or alternatively, introduce a new artifact for jdom 1.x code. In the balance of the options, the better solution is to introduce the new artifact for the 1.x code. Thus, JDOM 1.1.3 has now also been released as jdom-legacy-1.1.3 : http://search.maven.org/#artifactdetails|org.jdom|jdom-legacy|1.1.3|jar Rationale: ========== In hindsight, it was a mistake to release JDOM 2.x versions to the existing jdom artifact in maven. With the changed package from org.jdom.* to org.jdom2.*, there should have been a new artifact as well for JDOM 2.x Unfortunately, this mistake cannot be undone, leaving the maven system in a 'messy' state. Given all the complicated use-cases of maven users, and given the limited options available for 'correcting' the situation, it comes down to the weighing of pro's and con's and choosing a compromise solution. for non-maven users: there is no impact for 'simple case' maven users: there is no impact - they just continue using the 'jdom' artifact the way they always have. for 'complex case' maven users: the impact is very minimal - all they need to do is add a dependency on 'jdom-legacy'. Finally, the jdom-legacy solution has a very low risk. Example - Simple: ================= You have a project you are upgrading to use JDOM 2.x. All you need to do is change your JDOM dependency to version 2.0.2, pull in the new version with mvn, and fix your code to use the new org.jdom2.* packages. org.jdom jdom.dep 2.0.2 Example - Complex: ================== You are upgrading your project to use 2.x, but you have a dependency on some third-party code which in turn requires JDOM 1.x. For example your current dependencies may look like (htmlcleaner is a project that has a reference to JDOM 1.1 - http://search.maven.org/#artifactdetails|net.sourceforge.htmlcleaner|htmlcleaner|2.2|jar ): org.jdom jdom 1.1.3 net.sourceforge.htmlcleaner htmlcleaner 2.2 Now, if you want to upgrade your code to use JDOM 2.x, you would *want* to just change your version dependency from 1.1.3 to 2.0.2 as follows: org.jdom jdom 2.0.2 net.sourceforge.htmlcleaner htmlcleaner 2.2 Unfortunately though, your code will fail to compile/run because maven will 'pull' the 2.0.2 version of JDOM, and not 1.1 (the htmlcleaner version) and the htmlcleaner code will be referencing the package org.jdom.* which will not exist (JDOM 2.x has package org.jdom2.*) The *fix* for this problem is simple: all you need to do is, in your project, to also depend on jdom-legacy: org.jdom jdom 2.0.2 org.jdom jdom-legacy 1.1.3 net.sourceforge.htmlcleaner htmlcleaner 2.2 Rolf