Glen, Depends. Mavens transitive dependency mechanisms is one of the worlds depest mysteries.... (and changes from version to version :-( )
Seriously, if you have two dependencies that depend on different versions of XmlSchema transitively, what version you get is completely dependent on where in your pom they are and what version of Maven you are using. (as well as what JVM you were using, Sun/IBM/OSX/etc...) With 2.0.7+, a new algorithm was put in place to try and normallize that a bit. With 2.0.7+, it uses the version closest to the "root" of the tree. Consider your pom as the root. If one dep depends on XmlSchema 1.2 2 levels of transitively deep, and other depends on 1.3.2 3 levels deep, you will get version 1.2. If the two are the same level deep, I think it grabs the version from the dep found first in your pom. By putting it explicitely in your pom, that's level 1 so that will be grabbed. With XmlSchema, it also gets complex cause they keep flipping groupId's. Some things depend on org.apache.ws.commons:XmlSchema and others depend on org.apache.ws.commons.schema:XmlSchema. To maven, they are completely different and you can end up with both on the classpath and the "which one is first" could be relatively random. Dan On Thursday 24 January 2008, Glen Mazza wrote: > Placing this in the pom seems to allow it to work now (but it raising > another problem I'll start hunting down next): > > <dependency> > <groupId>org.apache.ws.commons.schema</groupId> > <artifactId>XmlSchema</artifactId> > <version>1.3.2</version> > </dependency> > > But adding this dependency to my pom.xml raises the question: why > would I need to explicitly include this, wouldn't it be normally > detected by Maven via the transitive dependencies required by CXF? > > Thanks, > Glen > > dkulp wrote: > > You need to update the version of XmlSchema. The version we used > > in 2.0.2 had too many bugs that we couldn't work around. In 2.0.3, > > it was updated to 1.3.2, which STILL has a bunch of bugs we cannot > > work around, :-( but it does fix a few others and does provide us > > an oportunity to work around a few others. We're trying to push to > > get a 1.3.3 released to fix some of the other issues, but they > > aren't being too helpful with that, which is frustrating. > > > > FYI: the ExtensionDeserializer dependency is to work around one of > > the bugs. The default extension deserializer loses most extensors > > (keeps only the last one) and treats namespace declarations as > > extensors as well. Thus, it loses things all over the place, > > especially with mtom schemas that throw xmime extensors on the > > base64 things. We created our own ExtenstionDeserializer that > > actually works correctly. 1.3.3 SHOULD be fixed, at which point > > we can remove our version. > > > > Dan > > > > On Thursday 24 January 2008, Glen Mazza wrote: > >> Hello All, > >> > >> As a result of upgrading from CXF 2.0.2 to 2.0.3, a test is failing > >> because the below class could not be found. > >> I'm using Maven for builds and tests, and am *not* bringing in > >> every possible CXF dependency as defined here[1]. > >> > >> java.lang.NoClassDefFoundError: > >> org/apache/ws/commons/schema/extensions/ExtensionDeserializer > >> > >> Question: Does anyone know what dependency am I missing, such that > >> this class can be found in 2.0.2 but *not* in 2.0.3? > >> (Alternatively, it is possible that this class is never used in > >> 2.0.2, hence why it works with that version.) > >> > >> Thanks, > >> Glen > >> > >> [1] > >> http://cwiki.apache.org/CXF20DOC/building-your-cxf-project-with-mav > >>en. html > > > > -- > > J. Daniel Kulp > > Principal Engineer, IONA > > [EMAIL PROTECTED] > > http://www.dankulp.com/blog -- J. Daniel Kulp Principal Engineer, IONA [EMAIL PROTECTED] http://www.dankulp.com/blog
