Why is Spring published under two different sets of artifacts?

Question

Whhy is Spring published under two systems of artifact names?

For example, the spring core is (usually?) used as

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>3.1.1.RELEASE</version>
</dependency>

(see: http://mvnrepository.com/artifact/org.springframework/spring-core/3.1.1.RELEASE )

but it is also published as

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>org.springframework.core</artifactId>
    <version>3.1.1.RELEASE</version>
</dependency>

(see: http://ebr.springsource.com/repository/app/bundle/version/detail?name=org.springframework.core&version=3.1.1.RELEASE )

Questions:

1. Why do they publish the same (?) jar as two different artifacts?

2. Which one should I use?

3. Why can I find the first jar in the maven central repository, but not the second jar? In which repository can I find the second jar?

Answer 1

The first is the standard packaging, the second is the OSGI-conforming version.

Answer 2

Check out Obtaining Spring 3 Artifacts with Maven on SpringSource Blog. It should answer all your questions:

In general, Spring publishes its artifacts to two different places:

1. Maven Central, which is the default repository Maven queries, and does not require any special configuration to use

2. The Enterprise Bundle Repository (EBR), which is run by SpringSource and also hosts all the libraries that integrate with Spring

So the first thing you need to decide when obtaining Spring with Maven is which place you'll get it from. In general, if you care about OSGi, use the EBR, since it houses OSGi compatible artifacts for all of Spring's dependencies, such as Hibernate and Freemarker. If OSGi does not matter to you, either place works, though there are some pros and cons between them. In general, pick one place or the other for your project; do not mix them. This is particularly important since EBR artifacts use a different naming convention than Maven Central artifacts.

... ...