开发者

Resin's `pomegranate' - auto-magical-loading maven jar dependencies for a project - but how to generate jars with pom.xml for them?

开发者 https://www.devze.com 2022-12-09 21:30 出处:网络
Resin java server has a neat feature they call pomegranate ( http://www.caucho.com/projects/pomegranate/ ) which allows to just put various jar dependencies in server\'s directory (project-jars/) and

Resin java server has a neat feature they call pomegranate ( http://www.caucho.com/projects/pomegranate/ ) which allows to just put various jar dependencies in server's directory (project-jars/) and then it loads them for a web-app from its pom.xml file.

Question is: how should I put the jars to resin's project-jars ? (just copying them doesn't work)

Detail开发者_运维百科s:

I have a working project with maven, with all dependencies configured in projects pom.xml file. I can build a webapp war etc.

I copied the jar files to resin's project-jars/ as they were generated by maven for this particular web-app.

When I deploy the war, resin spots pom.xml and tries to resolve dependencies; unfortunately it cannot find any artifacts in its repository (project-jars).

I suppose this is because all the jars I have put there do not have META-INF/maven/pom.xml files packed in them. They are just normal jars like those downloaded by maven.

On pomegranate website they say resin scans project-jars for jars with pom.xml files, to determine their versions.

How should I create jars with pom.xml files included?

Or should I manually copy the foo-bar-1.0.pom files from the repository on my devel machine to the resin's project-jars directory? (which kind of beats the purpose of all the auto-magic)

Thanks for answer,

Best regards

Horace


My understanding of the Pomegranate Draft specification is that:

Servlet containers can use pomegranate as an extension to the WEB-INF/lib with the following benefits:

  • Shared .jar files in a common repository, simplifying management and reducing .war sizes
  • Library dependency resolution, including the ability to handle sub-module incompatibilities
  • Familiar Maven pom.xml files, to take advantage of current development practices.
  • Optional integration with Servlet web-app containers
  • Optional integration with Java CanDI (JSR-299) managers

[...]

The web-app may contain an optional WEB-INF/pom.xml declaring the web-app's own dependencies.

So I guess the idea is to mark the dependencies as "provided" in the war pom.xml and to add them in WEB-INF/pom.xml for a deployment on Resin. I've not tested this though, so I might be wrong.

Actually, this pomegranate looks interesting but I don't get it entirely for now. While I understand its benefits, it seems to make the WAR not portable which is a big drawback. I'll dig it a bit further...

(EDIT: I'm putting an answer to a comment from the OP below)

To be honest, I don't find the spec draft very clear. However, I found this pomegranate modules post on Caucho's blog that details a bit more how to get it working for a webapp:

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

At least, I understand these steps and they answer your question: you have to drop the jars manually in Resin's project-jars directory. That's not what I was expecting but I think that I was misunderstanding what pomegranate is all about. If I'm not wrong, pomegranate is a kind of alternative to OSGI, it is about module bundling and classloading voodoo. It uses Maven's conventions to describe dependencies but it's not about dependencies management.

0

精彩评论

暂无评论...
验证码 换一张
取 消