台州建网站,广州seo优化方法,苏州网站建设中心,wordpress 数据库 清理熟悉发行版和快照依赖项的Maven和Gradle用户可能不了解TeamCity快照依赖项#xff0c;或者认为他们与Maven相关#xff08;这是不正确的#xff09;。 熟悉工件和快照依赖关系的TeamCity用户可能不知道#xff0c;除了TeamCity提供的插件之外#xff0c;添加Artifactory插… 熟悉发行版和快照依赖项的Maven和Gradle用户可能不了解TeamCity快照依赖项或者认为他们与Maven相关这是不正确的。 熟悉工件和快照依赖关系的TeamCity用户可能不知道除了TeamCity提供的插件之外添加Artifactory插件还使他们能够使用工件并建立依赖关系。 上面提到的某些名称似乎建立得不够充分而其他一些则可能需要讨论其使用方式。 考虑到这一点我决定在自己的博客文章中探索每种解决方案并设定了提供足够信息的目标以便人们可以选择最有效的方法。 第一篇文章探讨了Maven快照和发行版依赖关系。 第二篇文章介绍了TeamCity提供的工件和快照依赖关系第三篇也是最后一部分将介绍TeamCity Artifactory插件提供的工件和构建依赖关系。 内部和外部依赖性 通过签出整个代码库并从头开始构建应用程序构建过程可以完全隔离地运行。 对于项目将相关的二进制依赖项如果有与项目源一起保存在VCS中就是这种情况。 但是在许多其他情况下构建脚本依赖于某种内部或外部依赖性 。 内部依赖关系由我们自己的代码来满足在代码中我们可以完全控制该项目该项目可以分为多个模块或子项目。 外部依赖关系由其他人的代码我们无法控制来满足我们可以使用它或将其用作客户端。 这可以是第三方库例如Spring或另一个团队开发的组件。 这种区别非常重要因为内部和外部依赖项通常伴随着不同的发布和升级周期内部依赖项可以每小时进行一次修改重建和更新而外部依赖项的发布周期显着变慢因为用户应用更新的频率更低如果有的话。 这主要是由于内部依赖项受我们自己控制并且受到特定项目或模块的限制而产生了范围狭窄的影响而外部依赖项只能按原样使用其影响可能是公司或全球范围。 它们不受任何项目的限制可以在任何地方使用。 自然这需要更高的发行版稳定性兼容性和成熟度标准因此发行和更新周期较慢。 “内部与外部”相关性特征的另一方面表现为在构建脚本中如何指定其版本。 内部依赖关系通常使用快照版本定义而外部依赖关系则使用发行版本。 “快照”和“发布”版本的定义是Maven提出的Maven开创了通过构建工具管理依赖项的想法。 如果您熟悉自动依赖项管理请随时跳过以下部分其中提供了有关其工作原理的快速概述。 自动依赖管理 在Maven中依赖关系是在构建脚本中声明性地指定的此方法随后是一种较新的构建工具例如Gradle Buildr和sbt 。 Maven dependencygroupIdorg.codehaus.groovy/groupIdartifactIdgroovy-all/artifactIdversion1.8.6/versionscopecompile/scope
/dependency 摇篮 compile org.codehaus.groovy:groovy-all:1.8.6 生成器 compile.with org.apache.axis2:axis2:jar:1.6.1 sbt libraryDependencies org.twitter4j % twitter4j-core % 2.2.5 每个依赖项都通过其坐标和范围来标识。 坐标明确指定所使用的库和版本而范围则定义其在编译或测试调用等构建任务中的可见性和可用性。 例如 compile org.codehaus.groovy:groovy-all:1.8.6将为版本1.8.6指定一个Groovy org.codehaus.groovy:groovy-all发行版用于源代码编译和测试调用。 将范围切换到“测试”或“运行时”将把库的可见性分别缩小到仅测试或仅运行时。 当构建开始时依赖关系要么位于由构建工具管理的本地工件存储库中类似于浏览器缓存要么从远程存储库无论是公共存储库还是私有存储库下载例如Maven Central Artifactory或Nexus 。 然后构建工具根据其作用域将解析出的工件添加到相应的类路径中。 组装构建工件例如*.war或*.ear档案时所有必需的依赖项也会正确处理和打包。 尽管依赖关系管理似乎是几乎所有构建中必不可少的部分但并非所有构建工具都为其提供内置支持 Ant和MSBuild缺少此功能后来Ivy和NuGet在一定程度上解决了这一差距。 但是与Maven相比Ivy的采用速度较慢而NuGet是仅.NET的工具。 随着时间的流逝Maven工件存储库和Maven Central已经成为分布和共享Java工件的事实上的机制。 能够使用Maven存储库解析和部署这些资源已成为所有较新的Java构建工具的“必备”能力。 发行和快照依赖性 如前所述内部依赖关系通常使用快照版本定义而外部依赖关系则使用发行版本。 让我们先看一下发行版本因为它们更容易推论。 发行依赖关系是具有固定版本号的依赖关系 例如Groovy发行版的1.8.6版本。 无论构建使用什么工件存储库并且无论何时尝试查找此依赖项总是希望它解析出完全相同的工件。 这是发布依赖项的主要原理 “相同版本相同工件” 。 由于这个事实构建工具不会在发现发布依赖关系更新后对其进行检查并且仅在清空本地缓存后才会重新下载工件。 当然所有这一切都是有道理的因为我们永远都不会期望找到带有相同版本号的同一个库的不同工件 快照依赖关系是不同的因此处理起来很棘手。 快照依赖项版本以特殊的-SNAPSHOT关键字结尾例如3.2.0-SNAPSHOT 。 该关键字向构建工具发出信号以通过远程存储库定期检查工件以进行更新 默认情况下Maven 每天执行一次此检查。 快照依赖关系的功能那么是依靠别人的工作正在进行中想想“每日构建”当产品开发移动从版本X到版本X1的模块版本X1-SNAPSHOT 。 快照相关性不确定性 如果发布依赖关系的主要原则是“相同版本相同工件” 版本“ X”发布的库其工件在世界范围内永远相同则快照依赖关系的原则是“相同版本不断更新”神器” 。 这种方法的好处是它可以检索频繁的更新而无需产生非常不切实际的每日发布。 但是它的缺点是不确定性–在构建脚本中使用快照依赖关系会使得更难知道在特定构建执行过程中使用了哪个版本。 我的maven-about-plugin将文本“ about”文件存储在每个快照工件中以便更好地标识其来源例如VCS版本和内部版本号 这可能会有所帮助但只能解决一半问题。 作为其定义的移动目标快照依赖项不允许我们确定我们所依赖的版本因此很难实现构建的可复制性。 同样在一系列构建或构建管道中当完成的构建触发了后续构建的调用时初始管道步骤所产生的工件不一定会被关闭的那些消耗因为此后可能会被其他构建过程长时间覆盖与此同时。 在这种情况下一种可能的方法是使用时间戳 锁定构建脚本中的依赖项版本使其成为3.2.0-20120119.134529-1而不是3.2.0-SNAPSHOT 。 这有效地使快照依赖关系与发行依赖关系相同并禁用了自动更新机制从而即使在没有时间戳的情况下也无法使用最新版本除非更新了时间戳。 如您所见可以在有意义的地方使用快照依赖关系但应谨慎并小剂量进行。 如果可能最好为每个可重用组件管理一个单独的发行生命周期并让其客户端使用定期更新的发行依赖关系。 摘要 本文概述了Java构建工具对自动依赖项的管理并介绍了Maven版本和快照依赖项。 它还解释了快照依赖项的优势如何在构建可复制性和构建管道的背景下值得商de。 以下博客文章将探讨TeamCity构建链和Artifactory构建隔离这些构建隔离允许在整个构建链中使用一致可重现和最新的快照版本而无需在构建脚本中锁定其时间戳。 还有更多 参考来自Goldman 博客的JCG合作伙伴 Evgeny Goldin的Maven Build Dependencies 。 翻译自: https://www.javacodegeeks.com/2012/05/maven-build-dependencies.html
