我们将所有源代码的依赖第三方 JAR 与我们的源代码一起检查到源代码管理中。需要时,我们手动下载第三方 JAR 的更新,并将那些处于源代码控制中的 JAR 替换为较新的版本。我们还没有感觉到需要使用 Maven,因为这个过程对我们来说似乎足够简单。但是,如果不使用 Maven,我们是否会错过一些很有价值的东西?或者我们的场景不保证使用 Maven?
“JAR 变化不大”,我一直听到这样的说法......
在项目开始时,在 SCM 中存储 jar 很简单。随着时间的推移,罐子的数量变得越来越大......等待 2 或 3 年,没有人记得这些罐子来自哪里,它们的许可条款是什么以及最常见的版本是什么(在分析安全漏洞时了解这一点很重要) ……
我最近读过的关于存储库管理器案例的最好的文章是:
- http://www.sonatype.com/people/2012/07/wait-you-dont-have-a-repository-manager/
有点不敬,但确实对人们一直遇到的技术惯性提出了一个有效的观点。
将项目团队从 ANT 切换到 Maven 可能会很可怕......Maven 的工作方式完全不同,因此我发现它最好与新项目或富有冒险精神的项目团队一起部署。对于老派 ANT 用户,我建议使用阿帕奇常春藤插入。 Ivy 允许此类团队将其依赖项的管理外包,但保留他们熟悉的构建技术。
最终,使用 Maven 的最大好处不是依赖管理。这是标准化的构建过程。我见过几次创建“标准”ANT 构建过程的失败尝试。问题是,每个构建工程师对于标准应该是什么都有自己的看法……Maven 强制用户编写构建插件的方法一开始可能显得有限制性,但就像 iPhone 最终开发人员发现“有一个 Maven 插件可以解决这个问题”: -)
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)