Gradle – Maven的观点

正如我博客的读者所知道的， 我有点像Maven迷 。 我从2007年8月左右开始使用Maven，从没有回过头。 但是，就像其他所有情况一样，“变化是唯一不变的”。 现在这个领域还有其他参与者，Gradle看起来是最有前途的。 我决定试一试，并在本文中分享了我的发现/学习的要点（当然，一篇文章只能勉强刮伤表面，但这仍然是一个开始）。 如果您从事基于Java的项目，并使用Maven，则可能会发现这篇文章有趣。

什么是Gradle？

Gradle将自己介绍为企业自动化工具。 从我到目前为止所看到的，我倾向于同意，它的确似乎勾勒了旨在成为该框架的所有框框。 然而，这是一个有点的宏伟目标 ，salesy谈话。 拥有一个很好的目标（例如，尝试成为企业自动化工具），但我个人认为这是一个雄心勃勃，而不是现实。

从Java技术专家的角度来看，消除雄心和销售投入-Gradle（看起来像）Swift成为处理Java项目的所有构建和发布相关活动的好工具。

Maven对我来说很好。

是的，它确实。 我与一些相当大的企业一起工作，说实话，即使他们将所有Java项目都放在Maven上，他们也将取得长足的进步。 因此，就我个人的经验而言，在一家正规公司中，出于所有实际目的，Maven不仅足够好，而且如果得到正确和广泛的使用，也将是一个巨大的飞跃。

话虽这么说，虽然企业拥有使用工具和技术安全运行的奢侈品（甚至确实有这种需求），但我们的技术专家并不拥有奢侈品。 当工具/技术/框架证明自己很勇敢时，企业可以聘请知道这些工具（有时甚至是流行语）的顾问，而那些没有花费足够的精力来保持更新的技术专家可能会发现自己正在努力跟上。 诀窍是要知道哪些技术可以投入时间，哪些时间不可以。

至于Gradle，它设法吸引了一些真正令人印象深刻的顾客。 Spring人们已经将Spring核心转移到Gradle。 休眠的人详细记录了他们继续学习Gradle的原因。 Grails的人似乎对 Gradle 有强烈的意见 。

我不会尝试争取Gradle的好处。 首先，我对该工具还不了解。 其次，我已经分享的链接来自一些相当著名的公司，它们与相当成功的技术公司合作，并且他们在整合Gradle的好处方面做得很好。

我的简单总结是

1. Gradle允许您在Groovy中编写代码。 因此，无论您希望构建和发布脚本做什么，您都可以编写几乎任何代码。
2. Gradle-有机会向像Maven这样的先行者学习-似乎一开始就解决了一些问题。 处理多个模块，使用多个源文件夹等都是很好的例子。
3. 只要Maven不在身边，就意味着支持有些粗略。 的
   我使用的STS插件肯定有一些粗糙之处。
4. 由于您可以编写几乎任何所需的代码，因此轻松射击自己也很容易。 如此灵活-我认为对于企业来说，使用Gradle进行标准化的构建和发布跨项目将是一个艰难的时期。

所以，你去了。 两点赞成，两点反对。 相当平衡。 这足以使我感兴趣。 如果您也很感兴趣，请继续阅读。

那么，我该如何开始？

我建议您先为几个链接添加书签。 Gradle 主页 ， 下载页面 ， 相关工具列表。 电子书《 使用Gradle进行构建和测试 》。 完全值得注册。 我推荐它。 最后，您将在Gradle中花费更多的时间后，可以更好地理解Gradle用户指南 。

因此，继续下载最新版本。 我已经获得了1.3版。 解压缩并将其放在您喜欢的任何位置。 我通常将此类工具（基于Java的工具）转储到C：\ ProgramFiles（注意Program-？-Files之间缺少的空间）。 因此，对于本文，我有一个C：\ ProgramFiles \ gradle-1.3文件夹，其中包含我们刚刚下载的所有Gradle糖果。

我们需要稍微调整gradle.bat文件。 在批处理文件的开头添加一个JAVA_HOME。 Gradle需要有权访问机器的Java安装。 保留文件的其余部分。

文件：C：\ ProgramFiles \ gradle-1.3 \ bin \ gradle.bat

SET JAVA_HOME=C:\ProgramFiles\Java\jdk1.7.0_09
...
@if '%DEBUG%' == '' @echo off ...
...

现在，只是为了测试您是否已将正确的东西连接在一起，请创建一个批处理文件。 它只是一行，因此您可以在命令提示符下键入它。 但是我倾向于将其放入批处理文件中，因为稍后我倾向于在其中添加更多内容。

文件：C：\ ProgramFiles \ gradle-1.3 \ bin \ GradleCommands.bat

gradle -v

如果运行此批处理文件，您将看到Gradle宣布其版本。 如果您现在和我在一起，那么您的机器上可以运行香草Gradle。 恭喜你 但是，对于您的大多数实际目的而言，这还不够。 让我们对工具进行更多的介绍 。

我不再使用Eclipse。 STS确实做得非常好，我已经使用了几年了。 幸运的是，还有一个用于STS的Gradle插件 。 安装过程有详细记录，在此不再赘述。 但是，安装过程无法传达出它并不是那么简单。 我在两台不同的机器上尝试过它，不得不经历了好几次，才能使它起作用。 我的建议是不要在Eclipse / STS的工作安装中尝试它，除非您有能力将其破坏几个小时。 制作另一个STS实例并进行处理。 您的毅力将通过STS中的新Gradle导入功能（以及其他一些功能，我们将在后面进行检查）得到回报。

最后一件事–在继续之前，请在STS中打开“首选项”，并将Gradle设置为C：\ ProgramFiles \ gradle-1.3文件夹。 我想确保STS只是在运行香草Gradle，而没有其他任何操作。 如果需要，我可以退出STS并在命令提示符下键入相同的命令，并确保得到相同的结果。 我喜欢从编辑器执行操作，但是鄙视被锁定。完成后，您需要导入一个基于Java的项目（使用Gradle）。

如何创建基于Gradle的Java项目以导入STS？

这是乐趣开始的地方。 只需创建一个文件夹（我将其称为gradle001）。 在其中放入一个build.gradle文件。 现在，这就是STS导入它所需的全部。 build.gradle中包含一些理论。 我现在不会研究它。 让我们看看下面的build.gradle文件。

文件：/gradle001/build.gradle

apply plugin: 'java'

def localMavenRepo = 'file://D:/mavenrepo'
repositories {
    mavenCentral()
    maven { url= localMavenRepo }
}

sourceCompatibility = 1.7
version = '1.0-SNAPSHOT'
group = 'foo.bar.gradle'

dependencies {
   testCompile 'junit:junit:4.11'
}

您现在看到有趣的部分了吗？ 尽管我没有在文件中添加任何注释，但是您能猜出大多数说明是什么意思吗？ 我希望你们大多数人都能。 大家知道，我一直在使用Maven，本地存储库保存在D：/ mavenrepo。 使用Gradle，我可以重用该本地存储库，也可以使用Maven中央存储库。 从我的角度来看，Gradle不能与Maven友好，我喜欢Gradle尽力使开发人员的生活变得更加轻松。

现在，我们将启动STS（使用Gradle）并导入“新的Gradle项目”，然后在其中导入刚刚创建的文件夹结构。 如果一切正常，您将在STS的“项目浏览器”视图中很好地看到该项目。 我的个人经历对此有些粗略。 我必须尝试几次，然后才能使用它。 但是，一旦导入成功，事情就会变得更加顺利。

Maven曾经通过虚拟主类和测试类为我提供了更完整的项目。

是。 Maven曾经为您“创建”一个项目，您可以从许多模板（原型）中选择一个来创建您的项目结构。 las，我找不到Gradle的类似功能（正如我在本文开头承认的那样，我是此工具的新手，因此，如果我缺少任何内容，请告诉我。请发表评论）。

事实上，没有为您创建任何虚拟项目。 但是，工具的强度（例如Gradle）不是那样。 我们已经看到读取build.gradle很容易。 现在，让我们编写一些虚拟代码，亲自了解Gradle可以为我们做些什么。

文件：/gradle001/src/main/java/foo/bar/AppMain.java

package foo.bar;

public class AppMain {
 public static void main(String[] args) {
  System.out.println(new AppMain().greet());
 }
 public String greet() {
  return 'Hello world.';
 }
}

文件：/gradle001/src/test/java/foo/bar/AppMainTest.java

package foo.bar;

import static org.junit.Assert.*;

import org.junit.Test;

public class AppMainTest {

 @Test
 public void test() {
  assertEquals(new AppMain().greet(), 'Hello world.'); 
 }

}

更新的文件：/gradle001/build.gradle

apply plugin: 'java'

def localMavenRepo = 'file://D:/mavenrepo'
repositories {
 mavenCentral()
 maven { url= localMavenRepo }
}

sourceCompatibility = 1.7
version = '1.0-SNAPSHOT'
group = 'foo.bar.gradle'

dependencies { testCompile 'junit:junit:4.11' }

task(runSimple, dependsOn: 'build', type: JavaExec) {
 main = 'foo.bar.AppMain'
 classpath = sourceSets.main.runtimeClasspath
}

就这样。 现在，如果我们运行build.gradle的“ runSimple”任务，Gradle将为我们做很多事情。 它将进行标准的清理，编译，测试并生成测试报告（假设您到目前为止也已在编写代码，请在您的计算机中检出/gradle001/build/reports/tests/index.html。惊喜），建立并最终运行主类。 大约需要18行build.gradle。 我必须说，我认为这根本不是一件坏事。

有什么大不了的？

你是对的。 但是您错过了重点。 即使是25,000行代码，这18行构建脚本也可以正常工作。 如果您仍然不确定，我建议您阅读这篇文章，其中264行构建脚本似乎表现出色。

嗯……很好，但是Maven的“力量”也没有那么长吗？

你可能是对的。 尽管人们似乎针对这种可能性提供了各种各样的论据和数据，但我认为这不是要讨论的重点。

事实是Maven中的pom.xml只是一个配置文件。 在常规的一天，常规的构建和发布人员不会在Maven中编写任何代码。 当然，Maven允许您创建各种插件，它们可以解决“大多数”问题。 但是，似乎（最“最后”）才是争论的焦点。 在场景/需求不在“大多数”场景之外的地方，使用Maven是一件非常困难的事情。 随着技术生态系统变得越来越多样化，人们开始反抗这种束缚。

我个人认为这就是故事的发展方向。 批处理文件（xyz.bat）具有强大的功能，但是难以管理（很难读取）。 您必须为不同的操作系统编写不同的内容。 没有任务层次结构。 除了最琐碎的项目，我不知道有人喜欢维护它们。

因此来到了蚂蚁。 它还功能强大，并且在任务管理方面做得很好。 您拥有几乎所有目标的目标，而没有目标的目标则可以在批处理文件中编写代码，然后从Ant调用它。 达不到标准的地方。 人们在他们的项目中以各种可能的方式使用它，并且在大多数项目中，构建脚本本身就是一个项目。 他们很难管理，团队中只有几个人确切地知道他们的工作方式，没有人愿意修改它们。

这就是Maven获得重大成就的地方。 它以一致的方式满足了诸如魅力之类的“大多数”要求。 有一种固定的方法可以完成大多数事情。 因此，构建脚本不再是一个黑洞。 而且普通的Joe用Maven脚本射击自己的可能性较小。

有了Gradle，我们正以更大的力量调情。 期望普通的开发人员使用Gradle进行编码，而不仅仅是配置插件（如在Maven中一样）。 因此，普通开发人员会在自己觉得合适的情况下轻松完成工作。

恰恰是当项目冒着创建可能严重破坏构建脚本的风险，周围没有知识库的时候，开发人员会喜欢其中的编码，但讨厌维护它，管理人员会对构建脚本产生噩梦在演示前一天失败，将不得不忍受它。

那你到底在说什么

从我对Maven的了解（无论人们是否喜欢Gradle，人们似乎都同意我的观点），它对于标准/平均/大多数要求都做得很好。 它做得很好。 并且存在不允许您突破的界限，在此界限既可以视为a锁，也可以视为安全功能。 如果您要使用标准技术堆栈创建另一个J2EE Web应用程序/ Java桌面应用程序，我会说没有理由放弃Maven。 如果您还没有接受它，请这样做，您的生活会轻松得多。

但是，如果您在产品开发项目中，并且正在超越人们认为java / j2ee具备的能力的界限（并且假设您不只雇用普通的Joes），我想您可能想在Gradle尝试一下。 它确实有能力。 一起工作很有趣。 我认为Gradle的前进道路确实是光明的，充满了可能性。 花时间在上面是一件好事。

今天就这些。

如果您希望到目前为止阅读过，希望您喜欢它，或者至少发现它很吸引人。 我的文章仅基于我对Gradle的修改，而不是通过任何想象力得出的关于该主题的硬道理。 如果您发现任何错误或本文正确的内容，请在下面发表评论。 我将非常有义务。

参考： Gradle –我们的JCG合作伙伴 Partho在Tech for Enterprise博客上的Maven观点 。

翻译自: https://www.javacodegeeks.com/2013/01/gradle-a-maven-perspective.html