Since Spring has started its strong support for OSGi, all spring libraries have been turned into OSGi bundles internally. Subprojects (e.g. Webflow) eventually also started to publish their jars using the bundle naming scheme. With Spring 3.0 it looks we are at the final destination. As long as you stick to the more populare frameworks you get a pretty complete repository of Maven artifacts.
On one side it is good to see a unique naming for all of the spring + subproject artifacts. But for those of you starting to migrate existing projects this causes a few headaches. Everything is fine as long as you can get all of your favourite libraries from one of the SpringSpource bundle repositories
1 2 3 4 5 6 7 8 9 10 11 12 13 14
Fortunately they also provide a really helpful tool for searching their repositories.
But sometimes you won’t find your favourite ones and need to fall back to non-bundle style artifacts from non-Springsource repositories. And here is the trouble: SpringSource is renaming the Maven artifactId for all of the bundles stored in their repositories (e.g. com.springsource.org.apache.commons.logging is the bundle equivalent of org.apache.commons.logging).
So let’s say you depend on artifact A that comes from the bundle repository (that depends on logging) and also depend on artifact B that comes from the standard maven repository (and also dependes on logging). This will end up with a 2 dependencies to the logging artifact and Maven will not be able to distinguish since they have a different artifactId.
To resolve that, start adding dependency exclusions and dependencies for first level transitive dependencies.
I’m showing an example for the hades project that actually has a bug in their dependency description.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16