Java jar文件到存储库(CVS,SVN ..)

Question

为什么将Java jar文件提交到存储库(CVS,SVN ..)是个坏主意.

Answer 1

因为您可以从源重建它们.如果您正在讨论项目所需的第三方JAR文件,那么最好将它们提交到存储库中,以便项目是自包含的.

Answer 2

所以,你有一个使用一些外部依赖项的项目.这种依赖性是众所周知的.他们都有

• 一个组(通常是组织/伪造创建它们)
• 标识符(他们的名字)
• 厌恶

在maven术语中,这些信息称为工件(Jar)坐标.

我所讨论的依赖项是内部的(对于Web应用程序,它可以是您的服​​务/域层)或外部(log4j,jdbc驱动程序,Java EE框架,您的名字,......).所有这些依赖项(也称为工件)实际上是最低级别的二进制文件(JAR/WAR/EAR),您的CVS/SVN/GIT将无法有效存储.实际上,SCM使用的是版本化内容(diff操作最有效的内容)仅为文本的假设.因此,当存储二进制数据时,它们很少是存储优化(与文本相反,其中仅存储版本差异).

因此,我倾向于建议你使用依赖管理构建系统,如maven,Ivy或Gradle.使用这样的工具,您将在文本(或XML)文件中声明所有依赖项(实际上,在此文件中,您将声明依赖项的工件坐标),该文件将在您的SCM中.但您的依赖关系不会出现在SCM中.相反,每个开发人员都会在其开发机器上下载它们.

这将一些网络负载从SCM服务器传输到互联网(带宽通常比内部企业网络更受限制),并询问工件的长期可用性问题.这两个答案都得到了解决(至少在amven工作中,但我相信常春藤和gradle都可以使用企业代理,如Nexus,Artifactory和连接到这些工具 - 而且似乎有一些关于这个问题的问题).其他.

这些工具的优点在于它们可以在内部网络中提供所有必需工件的视图,从而允许您在这些存储库中部署自己的工件,使得代码的共享既简单又独立于源(可能是一个优势).

总结一下这个很长的回复:使用Ivy/Maven/Gradle而不是简单的Ant构建.这些工具将允许您定义依赖项,并完成下载这些依赖项的所有工作,并确保您使用声明的版本.

在个人笔记中,在我发现这些工具的那一天,我对Java的依赖处理的看法从噩梦到天堂,因为我现在只需要说我使用这个工具的这个版本,而maven(在我的情况下),完成下载并存储在我电脑上正确位置的所有后台工作.