Frequently Asked Questions

Answers

What is the current status of the repository?

The repository is frozen but will remain accessible until at least 1 September 2014. See http://www.eclipse.org/ebr/ for information regarding the Eclipse Bundle Recipes project to which users of the SpringSource Enterprise Bundle Repository should transition.

What is the SpringSource Enterprise Bundle Repository?

The SpringSource Enterprise Bundle Repository is a collection of open source libraries commonly used for developing enterprise Java applications with the Spring Framework. The repository contains jar files (bundles) and library definition (".libd") files. A library defines a collection of bundles that are often used together for some purpose (e.g. the "Spring Framework" library). There are hundreds of bundles contained in the repository.

The repository meets the following criteria:

  • Every jar file in the repository is a valid OSGi bundle. Any jar you download from the repository can be deployed as-is into an OSGi Service Platform and the SpringSource dm Server. It can also be used as a regular jar file outside of OSGi.
  • Every bundle and library has full version information associated with it. The package export information for a bundle contains version information, and the package import information for a bundle contains full version range compatibility information.
  • The repository is transitively complete. The mandatory dependencies of any bundle are guaranteed to also be in the repository. Most of the optional dependencies of any bundle in the repository will also be present. The bundles listed in any library definition are guaranteed to be in the repository.
  • The repository is self-consistent. Before any artefact is uploaded to the repository, we verify that it can be installed, resolved, and started in an OSGi Service Platform (using the same profile as the SpringSource dm Server) alongside all of the other bundles in the repository.
  • The repository can be used from Ivy and Maven based builds.

What is a Bundle?

Bundle is an OSGi Alliance term for a module in an OSGi Service Platform. A Bundle is packaged as a regular jar file with additional entries in its manifest. Every jar file in the repository is a valid OSGi bundle and can be deployed as-is into an OSGi Service Platform and the SpringSource dm Server. Bundles in the repository all define the following information:

  • Bundle-Name: the human-readable name of the bundle, for example, "Spring Core".
  • Bundle-SymbolicName: a string that (along with the version information) uniquely identifies the bundle. Symbolic names follow reverse domain-name conventions - for example, "org.springframework.core".
  • Bundle-Version: the version of the bundle, e.g. 2.5.4
  • Export-Package: the packages exported by the bundle. In OSGi only packages that are exported by the bundle are visible to other bundles. Packages that are not exported remain private to the bundle. When searching the repository for bundles providing certain classes or resources, only the exported packages are displayed and searched. Every package is exported with version information, for example, the Spring Core bundle, version 2.5.4 exports version 2.5.4 of the org.springframework.core package.
  • Import-Package: the package-level dependencies of the bundle. These may be optional or mandatory dependencies. Each import specifies the version range it is compatible with (e.g. "version 2.5.0 or higher").

What is a Library?

A Library definition file has a ".libd" extension. It defines a collection of bundles that are often used together. For example, a Spring Framework library might contain references to all of the bundles that comprise the Spring Framework. Library definition files are understood by the SpringSource dm Server and provide a convenient way for your application bundles to declare a dependency on a library by using the Import-Library manifest header. For example:

Import-Library: org.springframework;version="[2.5.4,2.5.4]"

Libraries in the repository all have the following information associated with them:

  • Library-Name: a human readable name for the library, for example, "Spring Framework".
  • Library-SymbolicName: a string that (along with the version information) uniquely identifies the library. For example, "org.springframework". Library symbolic names follow reverse domain-name conventions by default.
  • Library-Version: the version of the library
  • The list of bundles that are contained in the library.

What does it mean for the artefacts in the repository to be OSGi-ready?

Every jar file you download from the repository has the necessary manifest entries to be used as a bundle in an OSGi Service Platform and the SpringSource dm Server. You can use the jar files outside of OSGi just as you would any other jar file. Unless indicated otherwise, the jar files are identical to those provided by the relevant open source projects (e.g. commons-logging) with the addition solely of new manifest entries. In a small number of cases SpringSource have also needed to patch the source code of the bundle to ensure that class and resource loading performed by the bundle works correctly under OSGi. Bundles that have been patched in this way have a ".osgi" qualifier in their version. SpringSource submit these patches back to the open source projects in question with the hope that in time the need to patch libraries will diminish.

What license are the artefacts in the repository made available under?

The open source libraries contained in the repository use a variety of open source licenses. Any changes to the artefacts (such as the addition of manifest entries) are made available under the same license as the orignal arftefact. When looking at the details page for any artefact in the repository you will find a link to the license file right alongside the download and sources download links. SpringSource offers no indemnification for any artefacts in the repository.

How do I configure Ivy to work with the repository?

The bundle repository makes its artefacts available in a suitable format for use with the Ivy dependency manager. Configure Ivy to point to the SpringSource Enterprise Bundle Repository by adding the following resolvers:

<url name="com.springsource.repository.bundles.release"> <ivy pattern="http://repository.springsource.com/ivy/bundles/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /> <artifact pattern="http://repository.springsource.com/ivy/bundles/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /> </url> <url name="com.springsource.repository.bundles.external"> <ivy pattern="http://repository.springsource.com/ivy/bundles/external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /> <artifact pattern="http://repository.springsource.com/ivy/bundles/external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /> </url>

If you are using library definitions with the SpringSource dm Server you will need to add the following:

<url name="com.springsource.repository.libraries.release"> <ivy pattern="http://repository.springsource.com/ivy/libraries/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /> <artifact pattern="http://repository.springsource.com/ivy/libraries/release/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /> </url> <url name="com.springsource.repository.libraries.external"> <ivy pattern="http://repository.springsource.com/ivy/libraries/external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /> <artifact pattern="http://repository.springsource.com/ivy/libraries/external/[organisation]/[module]/[revision]/[artifact]-[revision].[ext]" /> </url>

Once Ivy is configured to look in the SpringSource Bundle Repository adding a dependency is easy. Simply pull up the details page for the bundle in question in the repository browser and you'll find an Ivy snippet ready for you to include in your dependencies section. For example:

<dependency org="org.springframework" name="org.springframework.core" rev="2.5.4.A" conf="compile->runtime"/>

How do I configure a Maven build to work with the repository?

The bundle repository makes its artefacts available in a suitable format for use with Maven. First define the SpringSource Bundle Repository to Maven as follows:

<repository> <id>com.springsource.repository.bundles.release</id> <name>SpringSource Enterprise Bundle Repository - SpringSource Bundle Releases</name> <url>http://repository.springsource.com/maven/bundles/release</url> </repository> <repository> <id>com.springsource.repository.bundles.external</id> <name>SpringSource Enterprise Bundle Repository - External Bundle Releases</name> <url>http://repository.springsource.com/maven/bundles/external</url> </repository>

If you are using library definitions with the SpringSource dm Server you will need to add the following:

<repository> <id>com.springsource.repository.libraries.release</id> <name>SpringSource Enterprise Bundle Repository - SpringSource Library Releases</name> <url>http://repository.springsource.com/maven/libraries/release</url> </repository> <repository> <id>com.springsource.repository.libraries.external</id> <name>SpringSource Enterprise Bundle Repository - External Library Releases</name> <url>http://repository.springsource.com/maven/libraries/external</url> </repository>

With the repositories configured, adding a dependency to a project is a simple matter of including the maven snippet displayed on the details page of each bundle when using the SpringSource repository browser. For example:

<dependency> <groupId>org.springframework</groupId> <artifactId>org.springframework.core</artifactId> <version>2.5.4.A</version> </dependency>

A enterprise library I need to use isn't in the repository, how do I get it added?

Users should first look to move to the Eclipse Bundle Recipes project (see http://www.eclipse.org/ebr/) and work with the Eclipse community to have bundles for new libraries created in a public repository. Alternatively, users can run Bundlor or bnd themselves to create their own bundles as needed.

How do I report a problem with a bundle or library in the repository?

Since the repository is frozen, the SpringSource Enterprise Bundle Repository JIRA is also frozen.

Why are JAR files named different than their common name?

The standard way to name a JAR in OSGi is by it's Bundle-SymbolicName or BSN. BSN's are derived from the packages inside of the JAR itself. For example, the name of the Expression Language API is not el-api (which is not it's package or BSN) but rather javax.el.

Why do the symbolic names of many bundles have a "com.springsource" prefix?

Most open source projects do not yet supply their artefacts with valid OSGi manifest header. SpringSource modified these artefacts to include the necessary headers before including the artefacts in the repository. Since the modified artefact is not identical to the original we needed to give it a distinguishing name. We named these modified artefacts with a com.springsource prefix. For example, "com.springsource.org.apache.xalan".

Why do the Spring bundles have a qualifier in their version number, for example the "A" in org.springframework.core-2.5.4.A.jar and the "RELEASE" in org.springframework.webflow-2.0.0.RELEASE.jar?

OSGi-compliant version numbers are of the format <major>.<minor>.<micro>[.qualifier]. The qualifier is optional, but all Spring projects use it to indicate the release type. The different release types are:

  • M - Milestone Release, e.g. M1, M2
  • RC - Release Candidate, e.g. RC1, RC2
  • RELEASE - Final release

In OSGi, qualifiers are sorted by their natural order. So 2.0.0.M1 comes before 2.0.0.RC1 which comes before 2.0.0.RELEASE. This ensures if version 2.0.0 is needed by an OSGi application, for example, the newest 2.0.0 release is selected.

The "A" qualifier in the Spring Framework 2.5.4.A bundles is used to indicate "slightly newer than 2.5.4". This qualifier was added because SpringSource patched the Spring Framework 2.5.4 jars to make them OSGi compliant. Future Spring Framework releases will adopt the standard version numbering scheme described above and will be natively OSGi compliant.