组织 Gradle 构建逻辑的任务或方法之间的最佳选择是什么？答案

【问题标题】：What's the best choice between tasks or methods to organize your Gradle build logic?组织 Gradle 构建逻辑的任务或方法之间的最佳选择是什么？
【发布时间】：2015-09-04 01:12:03
【问题描述】：

我目前正在将一些旧的大型 Maven 1 脚本迁移到 Gradle。因此，我需要将旧的 Maven 1 / Ant 及其目标逻辑调整到 Gradle。

在阅读了 Gradle 用户指南以及一些关于 Gradle 任务和方法的文章后，我对编写脚本的方式感到很困惑。

在官方Gradle User Guide, §6.1中解释了一个Gradle任务：

表示构建执行的一些原子工作

在§6.11中也说明了我们可以使用方法来组织我们的构建逻辑。

所以，我的问题是：使用它们的正确方法是什么？

我正在创建一个构建脚本，所以，在我看来：

任务应该只允许用户查看，因此，可以通过命令行调用。
例如gradle doSomeInternalTechnicalWork 对我来说不正确，因为用户甚至不应该知道doSomeInternalTechnicalWork 存在。
我始终认为，这应该不成为一项任务。
方法应该用于组织构建逻辑，并且不应该被用户看到

使用前一种逻辑，当我的方法需要调用 Gradle 任务时遇到问题（如 Java 插件的 JAR 创建）。

我知道I should not call task from task（方法中的任务也是如此），但是，看看这个例子：

task independentTask << {

   // initialization stuff 
   println "doing a lot of initialization" 

   // using methods to organize build logic, good or not?
   doComplexThingsThatTheUserShouldNeverDoHimself()
   }

task dependentTask(dependsOn: 'independentTask') << { 
   println "now that 'independentTask' is done, I can continue to do complex things..." 
   }

void doComplexThingsThatTheUserShouldNeverDoHimself() {
   println "doing really complex things"

   // I really need to create my JAR here and not somewhere else
   // And I know it's not a good thing to directly call the Action.execute
   jar.execute()

   println "doing other really complex things"
}

在这种情况下，正确的构建逻辑是什么？

是否应该将doComplexThingsThatTheUserShouldNeverDoHimself 转换为1 个或多个任务，以便能够dependsOn JAR 任务？
但这意味着有很多任务可以由用户调用，而实际上不应该是这样。

【问题讨论】：

您最好处理任务，因为它们可以更好地扩展且更易于管理。如果您有很多代码，请尝试将其放入 buildSrc directory 甚至制作插件。此外，这个问题看起来是基于意见的......

标签： methods gradle build logic task

【解决方案1】：

经过大量搜索，我得出结论，当您需要从另一个任务中调用任务时，您别无选择，只能依赖任务关系（ dependsOn, mustRunAfter, finalizedBy)。

这意味着方法不能像在 Java、Groovy & Co 中用于组织程序一样用于组织构建逻辑。

因此，您无法阻止用户查看（和使用）某些内部任务，这些内部任务通常只能被其他一些任务用作依赖项。

因此，以前构建脚本的“Gradle 正确”版本将是：

task dependentTask(dependsOn: 'doComplexThingsThatTheUserShouldNeverDoHimselfPart2') << { 
   println "now that 'independentTask' is done, I can continue to do complex things..." 
}

task doComplexThingsThatTheUserShouldNeverDoHimselfPart2(dependsOn: ['doComplexThingsThatTheUserShouldNeverDoHimselfPart1', 'jar']) << {
   println "doing other really complex things"
}

task doComplexThingsThatTheUserShouldNeverDoHimselfPart1(dependsOn: 'independentTask') << {
   println "doing really complex things"
}

task independentTask << {
   // initialization stuff 
   println "doing a lot of initialization" 
}

或者，单独声明任务关系：

task dependentTask << { 
   println "now that 'independentTask' is done, I can continue to do complex things..." 
}

task independentTask << {
   // initialization stuff 
   println "doing a lot of initialization" 
}

task doComplexThingsThatTheUserShouldNeverDoHimselfPart1 << {
   println "doing really complex things"
}

task doComplexThingsThatTheUserShouldNeverDoHimselfPart2 << {
   println "doing other really complex things"
}

// we declare all tasks relationships separately
dependenTask.dependsOn doComplexThingsThatTheUserShouldNeverDoHimselfPart2
doComplexThingsThatTheUserShouldNeverDoHimselfPart2 dependsOn doComplexThingsThatTheUserShouldNeverDoHimselfPart1, jar
doComplexThingsThatTheUserShouldNeverDoHimselfPart1 dependsOn independentTask

就个人而言，我更喜欢最后一个，关系块更具可读性。

【讨论】：