pomegranate modules
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:
- remove jars from your .war
- drop them in Resin’s project-jars directory
- declare jar dependencies in Maven .pom files
- 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:
Tags: module, osgi, pomegranate
June 16th, 2009 at 11:12 am
[...] wrote a quick overview of Pomegranate and we’ll soon have real docs for it, but I wanted to give the story of how we [...]
July 31st, 2009 at 4:31 am
You might take a look at POMStrap http://pomstrap.prefetch.com/en/ which has approximately the same goal.
July 31st, 2009 at 7:21 am
I love this idea as a simple alternative to OSGi!
I wondered if we could spin up a little OSS project somewhere neutral (say google code?) where we could describe the spec of how a pom.xml style dependency mechanism should work with any servlet container - then try get servlet containers to also implement it so it can become a common adopted standard?
e.g. we could patch the maven war command to optionally generate the pom.xml in WEB-INF. I was chatting to Greg from Jetty and he’s happy to support this model too - so we could get Maven, Resin and Jetty all supporting this simple alternative to OSGi?
Incidentally a suggestion from Greg was to consider putting pom.xml in the WEB-INF/lib, so when folks look in the lib dir for dependencies, they see the pom.xml there?
July 31st, 2009 at 9:27 am
alag: Thanks for the link! After just a quick pass, I don’t think that POMStrap is quite the same. They look like they’re inverting the classloader hierarchy, while we’re using a classloader cloud model. The difference is that the classloading is not transitive in any direction with our approach.
jstrachan: I like the idea. I’ll check with the rest of the team to see what they think. Standardization, specs, interoperability… all good stuff.
August 5th, 2009 at 12:46 pm
Awesome idea, congrats!
I’m working on Grizzly Servlet Container and would like to have this great feature there as well.
Please keep us posted on OSSing pomegranate.
August 5th, 2009 at 1:33 pm
I’ve posted a rough draft of a Pomegranate spec at http://blog.caucho.com/?p=225
August 7th, 2009 at 2:59 am
Emil: from my experience, not having transitive classloader could lead you to lot of ClassNotFound exceptions as most modules around here are not design with clean/strict dependency definition in mind.
August 17th, 2009 at 5:13 am
I downloaded the src of resin 4.0.0 and 4.0.1 but couldn’t find the pomegranate module while building locally.
August 17th, 2009 at 12:18 pm
It’s integrated with the Resin classloader in 4.0.1. Look at com.caucho.loader.EnvironmentClassLoader, ArtifactManager, Artifact, ArtifactClassLoader.
To alag. I think you’re right about the transitivity, but we also need a way to make a link intransitive for certain configurations. I’m hoping for another draft in a day or two.
August 17th, 2009 at 11:22 pm
Thanks for the info. In my project, I have 1 interface and 2 implementations. Each implementation has its own set of JAR dependencies some of which of may overlap. I am trying to see if I can use Pomegranate as an out-of-the-box solution for this. Any help is highly appreciated.