See also today's comment at http://blog.springsource.com/2008/12/05/spring-framework-30-m1-released/

Can someone explain why you changed the name of the maven artifacts?

What does this means? (from the readme.txt file) "Furthermore, the jar file names follow bundle repository conventions now."

If you look at the huge majority of Maven projects out there, everybody is using the same convention somehow (which is the one used in Spring 2.x artifacts).

Are you planning to setup a relocation so that users can safely upgrade from spring-beans 2.5.6 to 3.0.0 for instance?

I've seen many projects where stable modules use an old version of Spring. If you do this, the maven dependencies mechanism won't be able to resolve the version conflicts and users will get two version of Spring in their application

Stéphane
Maven PMC

Yes, I hope you'll at least handle the relocation, but I fear this won't be enough to be able not to have a 2.x and a 3.x spring jar in the same classpath. This is not a problem with OSGi, which seems to be why you changed your bundles naming, but you perfectly know it will be a big problem with "classical" classpath management.

If there's a change path to manage well, I guess this is one of the best to watch out .

Thanks

If you want to keep new artifact Ids, another idea is to propose a script to convert spring 2.X dependencies in 3.X. But it won't be easy.

Well, you will have to release a new version of your stable modules if you do that. I tend to think about the contrary (providing a script to generate artifactIDs 2.X with Spring 3.x artifacts)

I'd like to give a little background on exactly why the ID's have changed.

The biggest issue is that the primary distribution point for Spring 3.0 and beyond is the SpringSource Enterprise Bundle Repository http://www.springsource.com/repository. The ID's for this repository are based on the OSGi Bundle-SymbolicName as a rule. Therefore the ID's that you're running into now won't be changing.

As a side-effect of this, you cannot use the Enterprise Bundle Repository in combination with Maven Central; it's one or the other. Otherwise you may get duplicate copies of dependencies because Maven sees two different id's for the same JAR.

For the 3.0.0.RC1 release, we'll be providing Maven Central compatible POMs in addition to the standard Enterprise Bundle Repository POMs.

Hi,
Thanks for clarification.
–
Olivier

The POMs for individual modules, i.e orm, oxm, web.servlet, can be used for building a maven based spring project using the traditional names.

The top level all inclusive 'spring' POM can not be used, as modules in a pom are not treated as dependencies. This will be addressed in a future release if there is demand for it.

Note, the POMs can not yet be used to build and run unit tests, they are only sufficient for resolving dependencies.