我回顾了常春藤项目和道歉的用法，但我的结论是它过于复杂，原因如下：

• “编译”和“测试”目标分别发出对resolve任务的调用
• 每个插件还调用一个常春藤解决任务
• 维护类路径的复杂逻辑。可以使用cachepath任务和ivy配置进行简化。
• 构建插件不受常春藤（声纳，日食，老鼠）管理

我开始重构构建，但是当我意识到我不了解主要的坚果工件和插件之间的关系时不得不停下来……（我发现NUTCH-1515的方法很艰辛……浪费大量时间。
feed插件缺少相关性）。

我还注意到问题NUTCH-1371要求移除常春藤。如果不对当前代码库进行重大更改，这将是一个棘手的重构。我怀疑这将是一个多模块构建，每个插件都列出了自己的依赖关系。

总之，这项工作不能回答您的问题，但是我认为我至少需要记录几个小时的分析结果：-)鉴于NUTCH-1371，我不知道您的项目是否可以忍受主要的常春藤重构？

重构常春藤

这是我到目前为止所取得的成就：

• 坚果项目的私人“发展”分支
• 与树干的差异

好处：

• 单个常春藤报告显示所有配置（新的常春藤解决目标）
• 安装常春藤的新机制（新的常春藤安装目标）
• 使用ivy配置管理类路径（请参阅ivy文件中ivy cachepath任务和配置的使用）
• 使用常春藤自动安装的Eclipse，声纳和大鼠ANT任务（Eclipse插件值得注意，因为它使用打包程序解析器从tar存档中下载和提取jar）。

影响以下Nutch问题

• NUTCH-1881：此新方法删除了“解析测试”和“解析默认”目标，并使用常春藤代替$ {build.lib.dir}管理类路径。
• NUTCH-1805：可以凭借自己的依赖关系轻松地为作业目标设置单独的配置。
• NUTCH-1755：我认为可以通过为build.xml分配一个名称来解决此问题（请参阅：diff）