On Mar 31, 2012, at 10:23 PM, Stefan Bodewig wrote: > On 2012-04-01, Ralph Goers wrote: > >> From the vfs2 log it looks like it is running into a binary >> incompatibility with SLF4J. vfs2 is specifying SLF4J 1.5.5 but mvn >> dependency:tree is showing me that Jackrabbit is referencing >> jcl-over-slf4j and is using 1.5.3. I've added that to the vfs2 pom in >> hopes that Gump will honor it. > > It won't. Gump puts a proxy between mvn and the repo and always serves > the latest version by artifactId/groupId coordinates. If a project > breaks backwards compatibility without changing either of them Gump > doesn't provide any proper way to deal with it. > >> If it is trying to use the latest SLF4J then this can't be fixed as >> 1.6.0 introduced a breakage with LocationAwareLogger (at my request by >> the way). vfs2 doesn't actually use SLF4J - Jackrabbit does. > > Given VFS is not the only project suffering from this and the slf4j > project never asked for being included in Gump it might be the best idea > to stop building slf4j in Gump and give the remaining projects the > version they ask for.
Actually, I think there is something else wrong. I just looked at the last Gump run for VFS2 and it is complaining that there are multiple SLF4J bindings. The first is coming from slf4j-log4j12 which I believe binds SLF4j to Log4j. The second is coming from Jackrabbit itself. I did a jar -tf on jackrabbit-standalone-1.6.5.jar and it includes a whole pile of classes that aren't from Jackrabbit. I believe Gary added this to be able to test WebDAV directly during the build. I have no idea why we don't encounter any errors during the normal build as -X shows both jars are present on the test class path. Ralph --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
