OSGi Bundle Repository available for Enterprise Libraries

[Costin Leau]

# posting Adrian's email announcement:
Some of you may have seen the recent announcement of the SpringSource Application Platform (if not, a good starting point is Rob Harrop's blog here: http://blog.springsource.com/main/2008/04/30/introducing-the-springsource-application-platform/). The platform uses Spring and Spring Dynamic Modules as the end-user programming model, and contains a lot of smarts to make that model work smoothly with existing enterprise libraries.

Regardless of whether or not you choose to use the Platform, subscribers to this list will almost certainly be interested in the SpringSource Bundle Repository (http://www.springsource.com/repository). To support the development of enterprise applications with OSGi we've created a repository with nearly 300 of the most commonly used enterprise libraries when developing Spring applications. (Yes, this was a big and very resource intensive undertaking!) Every bundle in the repository has full OSGi manifests, and before any artefact gets into the repository it is verified in a running OSGi Service Platform to ensure it loads and resolves correctly.


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. 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 Application Platform) alongside all of the other bundles in the repository. * The repository can be used from Ivy and Maven based builds.

There is an FAQ here for those who are interested in further details http://www.springsource.com/repository/app/faq


Regards, Adrian.


The original email can be seen at:
http://groups.google.com/group/spring-osgi/browse_thread/thread/5c0db7a65ab4c86d
Related information is available at:
http://groups.google.com/group/spring-osgi/browse_thread/thread/efe9556718843d23

[Paul Newport]

Regardless of whether or not you choose to use the Platform, subscribers to this list will almost certainly be interested in the SpringSource Bundle Repository (http://www.springsource.com/repository).

I'm having quite a few issues with this repository when using IVY 1.4.1

What seems to happen on some bundles is that when a binary JAR file is requested as a dep, IVY actually pulls down a jar full of source code. Examples are:

<dependency org="org.springframework" name="org.springframework.context" rev="2.5.4.A" />

<dependency org="org.apache.log4j" name="com.springsource.org.apache.log4j" rev="1.2.15" />

<dependency org="org.hibernate" name="com.springsource.org.hibernate.annotations" rev="3.3.0.ga" />

This all works fine using IVY 2 beta. Not sure if this is the best place to report this problem but it's worth pointing out that the link to report a problem on the repository pages is broken too.

This is more or less a cross post from the core forum but I thought on reflection this was a better place to post.

[Costin Leau]

Thanks for reporting Paul - the best way to handle that is to raise an issue on the bundle repository issue tracker. Ivy is pretty good at backwards compatibility as far as I know so this might be just a matter of configuring ivy differently (but I might be wrong).

[topping]

This repository is a big help! I must have scanned this post once and have been using the link for some time, but didn't realize that the repository was transitively complete. That's really great.

For people new to SpringDM and OSGi, do yourself a favor on new projects: Only use dependencies that are hosted here, at least until you have a better idea of the mechanics of imports and exports. The result will be a much more stable environment to learn in.

Do you guys see a future where users can contribute to the repository? How do you plan to scale this to the size of the Maven repo?

Thanks!

[Costin Leau]

Fertroya, this is an announcement post. In the future, create your own topic rather then adding replies to an existing ones.
I'll reply here since this is your first post:
If you deploy your application as a bundle then yes, the library/jar needs to have the proper OSGi headers otherwise it's not a bundle. You can however embed the library (as it is, w/o being a bundle) inside another bundle but then it cannot be reused.

I recommend you start with some OSGi tutorials that provide an introduction to what OSGi is and how can you use it. There are also several blogs/articles on how to create OSGi bundles and one of them is written by yours truly and can be found here:
http://blog.springsource.com/2008/02/18/creating-osgi-bundles/

P.S. There is no need use bold characters for your questions. it makes your post harder to read and thus harder to read and easier to ignore.