java jar 依赖_Java JAR包含自己的依赖项是正确还是不正确...

术语“JAR文件”至少可以表示两件事,或者更确切地说,其含义至少有两个方面.最基本的,它意味着一种容器格式：基本上是一个带有META-INF目录的ZIP文件.更精确地说,它意味着此容器用作打包类文件的方法.

在作为容器的意义上,没有关于内容的意图;该文件可能包含类文件,其他JAR(在任何意义上！)等.但从作为代码打包的意义上讲,我认为正确的JAR文件的意图是它们不包含任何依赖项.

如果你读过JAR File Specification,你会发现存在类文件存储的几个暗示,但没有关于存储其他JAR文件的暗示.相应地,如果你看一下JRE中JAR文件类加载器的实现,它就无法对嵌套的JAR做任何有用的事情.

此外,JAR规范详细说明了处理非嵌套依赖项的机制：the Class-Path attribute.这使JAR文件可以对文件系统中的其他JAR文件进行相对引用.

现在,包装意义上的JAR文件并不是容器内JAR文件的唯一用途. WAR,EAR和RAR文件(以及更多文件)都是用于特定目的的JAR文件.其中每个都能够包含其他JAR：WAR可以包含包装内容的JAR文件,而EAR可以包含这些JAR文件和WAR.然而,那些与包装感知的JAR文件完全不同的野兽.值得注意的是,需要使用不在Java标准库中的特殊类加载器来使用它们.

WAR等可以将许多JAR文件收集在一起的方式确实非常有用,而且真正的遗憾是在Java EE之外的Java中没有通用的机制.拥有一个简单地捆绑一些JAR的“应用程序存档”或“元存档”格式会很棒.

所以,你留下了这个问题,用户需要25个JAR才能使用你的插件.你有两个选择.

首先,你接受了痛苦,并将你的插件分发为一个装满JAR的拉链,用户必须解压缩.

其次,您加入了21世纪,并使用自动处理依赖关系的构建工具和分发机制：在实践中,这意味着使用Gradle,Maven或其他工具(如Ant)与Ivy一起使用,以获取依赖关系Maven Central,然后释放您的代码以及列出这些依赖项的POM文件.然后,用户可以下载您的JAR和您的POM,并拥有自己的构建工具来获取依赖项.

如果您确实采用了第二种方法,那么为了不使用自动依赖关系管理的用户的利益,也可以谨慎地发布依赖关系的zip.