Created attachment 27057 [details] VersionChecker tool report Building my java project using Maven and JDK 1.5, after cleaning my local Maven repository, causes > java.lang.UnsupportedClassVersionError: Bad version number in .class file After investigations, it's because the batik artefacts version 1.7 required by the docbkx-maven-plugin are compiled using JDK 1.6 (see attached part of VersionChecker tool report).
Julien: why was this set as a regression? AFAIK, Batik previously wasn't available in maven at all... Although there have been recent discussion towards pushing the minimum requirement to 1.5 for the next release, for Batik 1.7 the minimum requirement is supposed to be 1.3 [1] (!). I'm Benson Margulies, as he was the one who helped towards publishing the maven artifacts. Benson: do you think it could be easy to republish the maven artifacts based on the original ones available for download [1]? (I'm assuming you probably don't have a JDK 1.3 or 1.4 handy.) [1] http://xmlgraphics.apache.org/batik/download.cgi
(In reply to comment #1) > I'm Benson Margulies, as he was the one who helped towards publishing the maven > artifacts Naturally, I meant "I'm CC'ing Benson" ;-)
(In reply to comment #1) > Julien: why was this set as a regression? AFAIK, Batik previously wasn't > available in maven at all... Well as explained in comment 0, Batik libraries are used in my project as a dependency of the docbkx-maven-plugin. As my project compilation used to work some times ago, I obviously wrongly assumed that the libraries haven been previously made available in Maven repo and built with JDK 1.4. Therefore I chose "Regression" as severity. Sorry for that. My current workaround, as I just can't compile using JDK 1.6, is to force the docbkx-maven-plugin version to a quite old version.
Well, this is a fine kettle of fish I've gotten us into. You can't 'republish' an artifact. They are immutable. We'd have to use a different version number, perhaps just -java.13 on the end, or with a distinctive Maven 'classifier'. Though I'm not too sure about retroactively adding new classified pieces. I didn't use the existing binaries because, ironically, I felt uncomfortable in signing binaries that I hadn't produced myself. Are you sure that there is a sufficient intersection of 'needs maven' and 'needs 1.3' to motivate fixing this? If so, the original binaries certainly could be published under a mutant version.
(In reply to comment #4) > Are you sure that there is a sufficient intersection of 'needs maven' and > 'needs 1.3' to motivate fixing this? If so, the original binaries certainly > could be published under a mutant version. Well, I'm not the one referencing the batik libraries... I'm using the docbkx-maven-plugin which uses batik libraries at runtime to generate documentation from DocBook content. If you do not replace the existing libraries in the Maven repositories, I'll have to secondly request a new version of the docbkx-maven-plugin to make them use the 'JDK 1.3' flavour of the batik libraries :-(
So, someone moved the docbk thing to the new maven version that lacks support for old java. I suppose they could move backwards. I'll look into republishing.