树脂的‘石榴’ - 自动神奇加载项目的 Maven jar 依赖项 - 但如何使用 pom.xml 为它们生成 jar？

发布于 2024-08-09 12:24:12 字数 817 浏览 9 评论 0原文

Resin java 服务器有一个巧妙的功能，他们称之为石榴 ( http://www.caucho.com/projects/ pomegranate/ ），它允许将各种 jar 依赖项放入服务器目录（project-jars/）中，然后从其 pom.xml 文件为 Web 应用程序加载它们。

问题是：我应该如何将罐子放入树脂的项目罐子中？（仅仅复制它们是行不通的）

详细信息：

我有一个使用 Maven 的工作项目，所有依赖项都配置在项目 pom.xml 文件。我可以构建一个Web应用程序战争等。

我将jar文件复制到resin的project-jars/，因为它们是由maven为这个特定的Web应用程序生成的。

当我部署战争时，resin 发现 pom.xml 并尝试解析依赖关系；不幸的是，它无法在其中找到任何文物存储库（项目 jar）。

我想这是因为我放在那里的所有罐子都没有 META-INF/maven/pom.xml 文件打包在其中。它们只是普通的罐子就像maven下载的那样。

在石榴网站上，他们说树脂会扫描项目罐子中是否有带有 pom.xml 文件的罐子，以确定它们的版本。

我应该如何创建包含 pom.xml 文件的 jar？

或者我应该从我的开发版本库中手动复制 foo-bar-1.0.pom 文件机器到resin的project-jars目录？（这击败了所有自动魔法的目的）

感谢您的回答，

最诚挚的问候

霍勒斯

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

时光倒影 2024-08-16 12:24:12

我对 Pomegranate Draft 规范的理解是：

Servlet 容器可以使用 pomegranate 作为 WEB-INF/lib 的扩展，具有以下优点：
在公共存储库中共享 .jar 文件，简化管理并减少 .war 大小
库依赖性解析，包括处理子模块不兼容性的能力
熟悉 Maven pom.xml 文件，以利用当前的开发实践。
与 Servlet Web 应用容器的可选集成
可选择与 Java CanDI (JSR-299) 管理器集成
[...]
网络应用程序可能包含一个可选的 WEB-INF/pom.xml 声明网络应用程序自己的依赖项。

所以我想这个想法是在战争 pom.xml 中将依赖项标记为“已提供”，并将它们添加到 WEB-INF/pom.xml 中以进行部署树脂。不过我还没有测试过，所以我可能是错的。

事实上，这个石榴看起来很有趣，但我现在还没有完全理解。虽然我了解它的好处，但它似乎使 WAR 不可移植，这是一个很大的缺点。我会进一步挖掘它......

（编辑：我正在回答下面OP的评论）

说实话，我认为规范草案不是很清楚。然而，我在 Caucho 的博客上发现了这篇石榴模块帖子，其中详细介绍了如何获取它适用于网络应用程序：

石榴旨在解决
模块版本控制和类加载器
来自企业应用程序的问题
看法。虽然我们正在做一个
背后的一些类加载器魔法
场景，开发者视角是
相当简单和干净：
从 .war 中删除 jar
将它们放入Resin的project-jars目录中
在 Maven pom 文件中声明 jar 依赖项
使用 WEB-INF/pom.xml 或在您的
树脂-web.xml

至少，我理解这些步骤，它们回答了你的问题：你必须手动将 jar 放到 Resin 的 project-jars 目录中。这不是我所期待的，但我认为我误解了石榴的含义。如果我没记错的话，石榴是 OSGI 的一种替代品，它是关于模块捆绑和类加载的巫毒。它使用 Maven 的约定来描述依赖关系，但它与依赖关系管理无关。

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:
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

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 原文

~没有更多了~