java - jar 应该有 "provided"依赖项吗？

Question

我们正在构建一个将在提供了 j2ee.jar 的 Websphere 上运行的耳朵。

现在我们遇到这样的情况，一个 ejb(称为 ejb.jar)依赖于另一个 jar(称为 util.jar)，而后者又依赖于 j2ee.jar。

如果在 util.jar 的 pom 中将 j2ee.jar 标记为“provided”，则不会构建 ejb.jar，因为 provided 不是可传递的。如果我们将其标记为“compile”，它可能会成为 ear 的编译依赖项，除非我们覆盖范围。

什么是最好的方法？ util.jar 是否应该提供依赖项，即使它只是一个简陋的 jar？或者 jar 应该只有编译依赖？

Answer 1

JAR 可以提供依赖项……但是依赖它的用户需要确保在运行时实际提供这种依赖项。由于提供的依赖项是不可传递的，因此它们还需要确保它们不依赖于它进行编译；但如果他们这样做，最好的做法是在编译(或提供)范围内显式声明它，并且不依赖某种形式的传递性(查看依赖插件的analyze目标，例如，列出已使用但未声明的依赖项)。

• JAR 中提供的依赖项在创建可执行 JAR 时很有用。考虑构建一个 uber-jar(一个 JAR，其中包含其所有依赖项的类):您可能想说特定的依赖项不应该最终出现在 uber-jar 中，因为启动它的容器将提供它在运行时。
• 此外，JAR 可能需要依赖项来编译其代码，但实际上并不需要它来运行；例如，考虑声明 maven-plugin-annotations as a provided dependency 的 Maven 插件因为他们只需要构建注释。
• 最后一点，有些 JAR 很清楚它们将在哪种上下文中使用:例如，Spring WebMVC 当然依赖于 Servlet API 进行编译，但在运行时，它知道它将要在 Java EE 上下文中使用，并且 Servlet API 将由 Java EE 服务器提供。

不过，根据经验，除了上述情况之外，您可能不想在 JAR 项目中提供 JAR 依赖项:应该由客户端来决定您的某些编译时依赖项是否是将针对他们的特定情况提供，并让客户覆盖范围。作为图书馆作者，您并不真正了解您的图书馆将如何使用。

在您的特定情况下，由于 ejb.jar 实际上需要 j2ee.jar 进行编译，因此最好在编译时声明该依赖性，甚至在在您的案例中提供了范围，无论 util.jar 为 j2ee.jar 设置了什么范围。 (我会注意到，实用程序 JAR 依赖于看似来自 Java EE Web 应用程序类的 JAR 是很奇怪的。)