使用Artifactory构建企业存储库

*本博客的内容是翻译自a博客发布葡萄牙语，迭戈·帕切科著．＊

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

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

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

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

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

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

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

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


使用Artifactory构建公司存储库

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

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

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

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


依赖控制

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


M2和Ivy统一存储库

上图显示，通过使用“虚拟”人工仓库，您可以同时为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并遵循本文中的模式和技巧，您都可以使用相同的存储库。

祝下次再见。