使用Artifactory构建企业存储库

*这个博客的内容是一个翻译博客发布葡萄牙文，作者迭戈·帕切科．＊

我清楚地记得DLL地狱同时主要负责微软的产品。hth华体会最新官方网站那时候我们深受依赖问题的困扰，直到今天我们依然如此。

当我开始使用Java时，我也遇到了类似的开发问题。具体情况略有不同，但问题的本质是相同的——依赖性。Java开发人员将这种体验称为JAR地狱．

令我惊讶的是，在2010年，公司仍然在这些问题上苦苦挣扎。解决依赖性问题有很好的解决方案。两个这样的解决方案是Apache Maven 2和Apache Ivy。这两个Apache解决方案都提供依赖项管理。

在Java应用程序的类路径中经常看到一个名为*lib*的文件夹，其中包含100多个jar。通常，70%或更多的这些jar是完全无用的，从未使用过，从未被系统ClassLoader接触过，或者很少被任何系统或用户定义的ClassLoader访问。尽管如此，它们仍然保留在建筑中。但是为什么呢?为什么要这样离开很多很多罐子来膨胀应用程序?原因有二:

1. 依赖问题:每个人都可能见过名人ClassNotFoundException在某个时期。通常，这个问题可以通过将我们使用的应用服务器和框架发行版中的所有jar复制到旧的*lib*文件夹中来解决。当然，这不是一个优雅的解决方案，也不是一个好的解决方案，但它被广泛使用，因为它易于实现并且节省时间。你不得不面对的问题是，你正在囤积一堆你不需要的罐子，你的应用程序的大小将会膨胀．注意:更健壮的应用程序服务器(例如Websphere)允许您创建共享库。您不必将所有的罐子都打包到您的发行版中(即。耳朵， war, jar)，因为你可以让服务器把它们放在类路径中。
2. 无知:许多公司仍然没有使用任何依赖管理解决方案。作为一个咨询我我在巴西和国外见过很多这样的情况。也许有些公司认为他们的开发人员即使没有花哨的管理解决方案也能做得很好。我们其余的人将投资于依赖管理解决方案。就我个人而言，我喜欢Maven或Ivy来解决依赖关系。

• 传递依赖关系:更容易找到那些难以捉摸的依赖关系
• 版本控制：使用“dump it in the *lib* folder”的方法有无法控制需要哪个版本或正在生产或开发哪个版本。依赖项管理框架为您提供了细粒度的控制，而不会让您发疯。
• 自动下载:使用依赖项管理解决方案，您不必搜索依赖项、下载它们并放置它们成应用程序的类路径。这是一个巨大的优势。
• 版本更新:这里为您处理了另一个令人头痛的问题，特别是如果您有几个应用程序使用您内部开发的jar时。好依赖项管理使您不必手动检查每个应用程序来执行版本更改。这将为您节省一些真正的艰苦工作和大量的时间。

我希望您已经相信使用Ivy或Maven这样的依赖管理解决方案是一个好主意。也许你已经在用其中一种了。

通常，使用Maven或Ivy的公司会忘记设置一个好的企业存储库解决方案这一切的背后。


使用Artifactory构建企业存储库

我以前使用过Java企业存储库解决方案，比如Nexus和Archiva。最近我只使用Artifactory我从来没有理由回头看。Artifactory是一个非常优雅的依赖管理解决方案。我遇到的主要问题Archiva它下载和解析依赖项的速度相当慢。

首先，我推荐Artifactory，因为它在下载和解析依赖关系方面做得更好更快。

其次，我衷心推荐使用Artifactory，因为它提供了一个舒适的web UI来管理你的第三方jar(解决方案和插件)，如Spring, Hibernate, JBoss，以及管理那些由你公司自己生产的。这种分离可以使用Artifactory的存储库来完成。

第三，我强烈推荐Artifactory，因为它提供了许多版本的开发和生产材料的分离和控制。大多数情况下，人们只将Artifactory用作代理解决方案，帮助您节省公司的一些流量频宽，但实际上要多得多。


依赖控制

Artifactory控制用户和组的权限。您可以决定哪些应用程序可以使用或使用某些存储库和jar。例如，您可以限制Spring仅用于某些项目。I wouldn’t do that but it can be done.Artifactory还通过限制和集中对这些依赖项的访问，为您提供了更好的方法来管理内部依赖项和您编写的解决方案。您可能再也不会错过依赖项了。


M2和Ivy Consolidated Repository

上图显示，通过使用虚拟Artifactory存储库，您可以同时服务Ant-Ivy和Maven客户端。最酷的是，您可以从同一个存储库为两个客户机提供服务。

这怎么可能呢?因为Artifactory是灵活的。

Artifactory在Maven 2依赖项标准下工作。本标准包括:

• GroupId：解决方案的组、模块的宏组或提供公司(例如。org．springframework）
• ArtifactId：表示或标识可用/消耗的工件——可以是jar的名称，就像我们以前的*lib*文件夹中那样(例如:春天）
• 版本:jar的版本(在Maven中，当我们看到类似1.0的版本时，通常表明该解决方案是生产版本，如果可用，您应该使用GA。在开发解决方案时，使用SNAPSHOT版本;有时后面跟着最后一次构建的日期和时间。)

对于Ivy，属性中的工作原理基本相同组织分别维护Maven 2的等价性:

• 组织：类似于Maven GroupId
• 模块:类似于Maven ArtifactId
• 修订:类似Maven版本

这两个Apache Dependency解决方案之间的最大区别是Ivy使用了一个正则表达式样式模式进行依赖项解析，而Maven使用预定义的模式进行依赖项解析。事实上，常春藤给了你更多的灵活性，但也要求你付出更多的努力。我的建议是对Ivy使用相同的Maven模式，这样部署到Artifactory将是一致的。通过这种方式，您将能够对Ivy和Maven使用相同的存储库。


配置Ivy以下载并部署到Artifactory

要做到这一点，您所要做的就是使用我命名为ivy-的XML文件artifactory设置．xml:

1<ivysettings>2<设置defaultResolver =“公共”/>3.<凭证领域=“Artifactory领域”4主机=“seu_host_do_artifactory”5用户名=“admin_user”passwd =“admin_password”/>6<解析器>7<ibiblioname =“公共”m2compatible =“真正的”8根=“http：/ / seu_server：8080 /artifactory/9seu_proxy_repository”/>10<urlname =“publish_artifactory”m2compatible =“真正的”>11<artifactpattern =“http：/ / seu_server：8080 /artifactory/12seu_repositorio_release_repository / (组织］/13(模块］/(修订］/(工件］——(修订)．(ext) " / >14url>15解析器>16ivysettings>

不要忘记使用[组织］/(模块］/(修订］/(类型］s /[工件］——(修订)．[ext]解析依赖项。当您通过Ivy发布您的jar时，您可以使用一个任务来基于Ivy的依赖项创建Maven POM。应该是这样的:

1<常春藤-makepomivyfile =" $｛艾薇．xml．文件}”2pomfile =" $ {basedir} / dist / $ {ivy.organisation｝/3.＄｛艾薇．模块｝美元/｛艾薇．修订｝/4＄｛艾薇．模块｝- $｛艾薇．修订}．砰的一声＂>5<映射参看=“默认”范围=“编译”/>6<映射参看=“运行时”范围=“运行时”/>7ivy-makepom>

考虑到您在dist文件夹中创建了jar，并且它遵循Maven 2模式，您将注意到它位于组织、模块和版本文件夹的层次结构中，并且jar被标记为模块名称和版本。

使用Maven消费和发布工件不会给您带来任何麻烦，因为Ivy现在遵循与Maven相同的模式。

因此，无论项目是使用Maven 2还是Ant with Ivy，通过使用Artifactory并遵循本文中的模式和技巧，您都可以使用相同的存储库。

祝你下次再见。