你应该在客户端jar中提供依赖库吗？ [英] Should you provide dependent libraries in client jar?

问题描述

我们正在为其他内部应用提供客户端jar，以连接到我们应用的REST API。我们的API依赖于一些标准的Jakarta库。将这些JAR文件包含在我们的客户端jar文件中是最佳做法吗？或者你只记录依赖关系，并由客户确保他们的类路径上有这些jar？

We're providing a client jar for other internal apps to connect to our app's REST API. Our API depends on a few standard Jakarta libraries. Is it a best practice to include those JAR files within our client jar file? Or do you just document the dependencies and it's up to the clients to ensure they have those jars on their classpath?

推荐答案

你应该不将任何第三方罐子作为超级罐子捆绑到你自己的罐子里，但最好在你的发行版中包含所有jar的副本，比如说在lib目录中或者什么都有。

You should not bundle the any third party jars into your own jar as an uber jar, but it would be good to include a copy of all the jar's that are required in your distribution say in a lib directory or what ever.

主要原因是您的客户可能正在使用某种形式的依赖管理系统（maven / ivy等）并提供实际上并不实际的包和类属于你的项目将使这些方案无效。

The main reason for this is that your clients may be using some form of dependency management system (maven/ivy etc) and providing packages and classes that don't actually belong to your project will invalidate these schemes.

有一种选择，就是使用像 maven shade plugin 将您的依赖项重定位到您自己的包命名空间中。这当然有一个缺点，你将增加库的代码大小，但从好的方面来说，你可以几乎保证你的依赖项的版本，而不影响你的客户可能使用的任何其他库。

There is one alternative and that is to use something like the maven shade plugin to relocate your dependencies into your own package namespace. This of course has the down side that you will increase the code size of your library but on the up side you can almost guarantee the versions of your dependencies with out effecting any other libraries your clients may be using.

编辑：以回应Marcus Leon评论：

in response to Marcus Leon comment:

可能的解决方案捆绑/重新定位：

Possible solutions with out bundling/relocating:

• 文档，确保记录您的依赖项以及与以前版本的任何已知冲突 - 没有人真正读取它


• 通过依赖管理系统分发您的库...像maven或ivy repo，这些允许您在非常具体的边界集（包括上层）中记录您的依赖项 - 仍然可以覆盖只有你的客户才会知道他们正在这样做


• 在MANIFEST.MF中添加OSGi信息 - 仅在客户实际使用OSGi时有用


• 如果您的依赖项是使用maven构建的，或者在那些清单文件中有版本信息，您可以编写某种检查例程，扫描类路径以查找这些并检查那些版本 - 有点极端

• Documentation, make sure you document your dependencies and any known conflicts with previous versions - nobody actually reads it
• Distribute you library via a dependency managed system... like a maven or ivy repo, these allow you to document in a very specific set of bounds (including upper) what your dependencies are - can still be overridden just your clients will know that they are doing it
• Add OSGi information in the MANIFEST.MF - only useful if your clients actually use OSGi
• If your dependencies have been built using maven or have version information in there manifest files you could write some sort of checking routine that scans the classpath for these and checks there versions - a bit extreme

最后实际上非常难确保你拥有你想要的依赖关系，因为java是一种后期绑定语言，你可以让你的依赖关系（即使捆绑）被你的类路径之前的某个人覆盖，包括不同的版本。

In the end it is extremely hard to actually ensure you have the dependencies you want as java is a late bound language it is possible to have your dependencies (even if bundled) overridden by somebody including a different version before yours on the classpath.

注意：我最近花了一个非常糟糕的一天试图找出我们的某个应用程序未能找到新版本的log4j的原因。原因：有人试图将其捆绑成一个随机完全无关的罐子。

Note: I've recently spent a very bad day trying to find out why one of our apps failed to find a new version of log4j. the cause: somebody trying to be helpful had bundled it into a random completely unrelated jar.

这篇关于你应该在客户端jar中提供依赖库吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！