Question

在我的公司，我们正在Hadoop上开发MapReduce应用程序。关于这些项目的依赖管理存在争议，我想听听你的意见。

我们正在使用Cloudera的Hadoop发行版（CDH）。

我们的开发工作流程：

MapReduce项目托管在SVN repos
每个人都有一个POM文件，其中定义了依赖关系（以及其他一些东西）
我们还创建了Oozie工作流项目，这些项目将这些MapReduce项目定义为POM中的依赖项，并负责定义MapReduce项目的执行流程
Oozie项目的构建工件是一个jar文件，其中包含它使用的所有MapReduce jar及其依赖项（我们使用Maven的程序集插件来压缩它），这是我们后来部署到HDFS的工件（解压后）
我们使用由Jenkins管理的Maven构建项目
成功构建部署到Archiva服务器
按照Archiva的要求部署到HDFS，获取Oozie项目构建的工件，将其解压缩并将其放入HDFS
构建项目不需要一些依赖项（即Oozie使用的; Hive，Sqoop，MySQL连接器，Jline，commons -...等），但它们需要它才能工作

还在我身边吗？

现在争论的焦点是定义MapReduce和Oozie项目的这些依赖关系。有两个观点。

有人说不需要在POM文件中定义这些依赖项（即构建项目不需要的依赖项），而是将它们放在HDFS的共享目录中，并始终假设它们在那里。

优点：

开发者不需要照顾这些（但是，他们照顾其他人）
最有可能的是，在更新CDH发行版时，在共享目录中更新这些内容比在每个项目个性中更新（不确定是否有必要）

缺点：

为项目定义了一些依赖项，有些假设感觉不对
共享目录可以成为未使用的JAR的接收器，没有人知道哪个仍在使用，哪个不是
代码变得不那么便携，因为它假设这些JAR总是存在于具有正确版本的HDFS中

那你们觉得怎么样？

编辑：忘了写，但很明显，第二个选项是定义所有依赖项 - 即使它们将重复大多数项目并需要一些维护。

Answer 1

我为第二个投票，这意味着处理和维护每个项目的依赖项而不是共享目录。导致问题是共享目录将随着时间的推移而改变，并且在一段时间之后其他项目将不再工作，因为有人删除了一些依赖项等。所以最好将依赖项保存到它们预期的pom中。此外，任何项目都将开箱即用，而不依赖于共享目录的当前状态。

您可能会想到一个父pom，它包含一些应该使用的默认依赖项。这可以通过dependencyManagement部分中的定义来处理，并且特定项目定义没有版本的真实依赖项。另一种解决方案可能是使用import scope。

<dependency>
  <groupId>yourGroupIdy</groupId>
  <artifactId>YourArtifactId</artifactId>
  <version>1.0</version>
  <scope>import</scope>
</dependency>

通过这个，可以有一组定义的依赖项，只需要在这个负责依赖项的单个pom项目中维护每个项目。

定义MapReduce项目和Oozie工作流的依赖关系

1 个答案: