This is a very rough draft of a pomegranate specification. It should contain the main details needed for an early implementation.
(more…)

There’s been a lot of hype around OSGi over the last year or two in the enterprise space. Last year even Caucho dallied with adding OSGi support to Resin, though we’ve abandoned the idea in the meantime. In this post, I’ll tell you what’s cool about OSGi, why we were initially attracted to it, why we eventually dropped it, and what we did instead. The more I talk to enterprise developers who’ve actually used OSGi, the more I hear this same story.

Update: Rob Harrop informed me that there is an emerging specification called RFC-66 for enterprise web/OSGi integration.
(more…)

As a quick introduction to pomegranate (I’m crushed for time today), here’s a quick diagram that shows the basic module structure for a typical pomegranate configuration.

Pomegranate is designed to solve the module versioning and classloader issues from an enterprise-application perspective. Although we’re doing a bit of classloader magic behind the scenes, the developer perspective is fairly simple and clean:

1. remove jars from your .war
2. drop them in Resin’s project-jars directory
3. declare jar dependencies in Maven .pom files
4. import them to your web-app with WEB-INF/pom.xml or in your resin-web.xml

Pomegranate resolves the module versions, and builds a classloader graph for the web-app. The module graph looks like the following: