使用Artifactory构建企业存储库

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

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

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

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

在包含100多个jar的Java应用程序的类路径中，经常会看到一个名为*lib*的文件夹。通常，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构建企业存储库

我过去使用过诸如Nexus和Archiva这样的Java企业存储库解决方案。最近我只使用Artifactory我从来没有理由去回顾过去Artifactory是依赖管理的一个非常优雅的解决方案。我的主要问题是Archiva它下载和解决依赖关系相当缓慢。

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

其次，我衷心推荐使用Artifactory，因为它为管理第三方jar(解决方案和插件)提供了一个舒适的web UI，如Spring、Hibernate、JBoss，以及管理那些由公司自行生产的jar。这种分离可以使用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

要实现这一点，您所要做的就是使用这个XML文件，我将其命名为ivy-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和Ivy，通过使用Artifactory并遵循本文中的模式和提示，您将能够对所有内容使用相同的存储库。

祝你下次再见。