Gradle 的目的是什么? [英] What is the purpose of Gradle?

问题描述

我可以在 Android Studio 0.4.0 的上下文中帮助理解 Gradle(插件 v 0.7)背后的概念.我以前没有使用过 Gradle，它给我带来的只是问题.我没有看到它的目的/好处，因为我对它的了解还不够.

I could use a little help understanding the concepts behind Gradle(plugin v 0.7) in the context of Android Studio 0.4.0. I have not used Gradle before and it's causing me nothing but problems. I'm not seeing its purpose/benefit because I don't know enough about it.

我有一些具体问题

1. 这些依赖是什么?我正在制作一个简单的应用程序导航抽屉，针对 API 11+，它应该在本地支持的.我可以使用哪些依赖项?

1. What are these dependencies? I'm making a simple app with a navigation drawer, targeted to API 11+ where it should be natively supported. What dependencies could I be using?

什么是 Gradle 包装器?如果有的话，它会对已完成的应用程序进行哪些更改?

What is a Gradle wrapper? What changes, if any, does it make to the completed application?

为什么 Gradle 需要一直在线?我没有我在工作时在我的个人笔记本电脑上访问互联网.得到了以至于我无法运行或测试我的应用程序，因为 Gradle 不能解析一些没有互联网访问权限的资源.

Why does Gradle need to be online constantly? I don't have internet access on my personal laptop when I'm at work. It's gotten to the point that I can't run or test my app because Gradle can't resolve some resource without internet access.

为什么 Gradle 使用 Groovy 很重要?我已经搜索过了在互联网上，这往往是人们喜欢的东西Gradle 但他们通常不会解释为什么 Groovy 很重要或它对 Android 应用有何作用.

Why is it important that Gradle uses Groovy? I have searched around the internet and that tends to be something people like about Gradle but they don't usually explain why Groovy is important or what it does for an Android app.

有时，作为一名中级程序员很难，因为信​​息往往过于简单或过于复杂.除了我的具体问题之外，您可以提供的任何其他信息都会有所帮助.我不想讨论 Gradle 与其他可能做同样事情的工具的优缺点，我只想了解更多关于 Gradle 及其使用的信息，以便我做出明智的决定.

Sometimes it's tough as an intermediate programmer as information tends to be overly simple or overly complex. Aside from my specific questions, any additional information you can provide would be useful. I'm not looking to debate the pros and cons of Gradle vs other tools that may do the same thing, I'd just like to know more about Gradle and its use so I can make informed decisions.

谢谢

推荐答案

您的一些问题很笼统，因为它们说明了为什么构建工具是一件好事.其他人则专门使用 Gradle.我将尽量简洁地处理这两个类别，同时尽量避免使用其他人挑剔的术语.

Some of your questions are general in that they speak to why build tools are a good thing as a general matter. Others get to Gradle specifically. I will try to address both categories as succinctly as possible while trying to avoid others' nitpicking terminology.

构建工具，如 Maven、Gradle、SBT、Leiningen 等，有助于自动化我们原本必须手动执行或手动自动化"的任务.我使用后者来描述我过去使用 Ant 所做的事情——编写自定义任务来编译、运行、生成 Javadoc 等，以便将来可以自动执行这些任务.通过遵守最初由 Maven 定义并随后被其他人采用的约定(例如将您的源代码放在 src/main/java 中)，这成为可能.如果我遵循这些约定，构建工具可以编译、运行、生成 Javadoc、测试以及其他所有内容，而只需最少的额外工作.

Build tools like Maven, Gradle, SBT, Leiningen, etc. help to automate tasks that we would otherwise have to manually perform or "manually automate." I use the latter to describe what I used to do with Ant--writing custom tasks to compile, run, generate Javadoc, etc. so the tasks could be automated for the future. By conforming to conventions originally defined by Maven and adopted by the others subsequently (like putting your source in src/main/java), this becomes possible. If I follow the conventions, the build tool can compile, run, generate Javadoc, test, and everything else with minimal extra work.

现在回答您的问题(按顺序):

Now to your questions (in order):

1. 构建工具的另一个关键功能是通过跨构建以一致的方式管理依赖项来减少jar 地狱".我只是指定我想要的 Apache Commons 或 Google Guava 或 Spring 或 Jackson 的版本(甚至版本范围)，构建工具将下载它们并将它们放在某个地方，以便它们可以在类路径和构建中(如适用)一个战争文件).我还可以定义范围——就像我希望这个依赖项在编译时可用，但另一个只在运行时可用.我是否需要明确提供它，或者它是否可用?诸如此类.
2. 这是 Gradle 特有的.如此处所述，Gradle 包装器可帮助团队运行 Gradle，而无需手动安装 Gradle，同时还维护一致性.每个人都使用相同的版本.一旦你设置好了，你就不必担心它，你想使用的所有 Gradle 任务都可以通过包装器获得，所以你甚至不需要关心它是否在那里.可以选择直接安装Gradle，直接运行，不过我很少看到重点.
3. 这是一般情况.我之前提到了依赖管理.为了获取这些依赖项，构建工具需要从 Maven Central 或一堆第三方存储库中获得这些依赖项.其他人采用的另一个 Maven 创新是存储库管理，因此编译的工件根据约定发布到存储库，以便其他项目可以使用它们.通常，你不会关心这个.您只需告诉工具您需要某种依赖项，它就知道如何获取它，因为每个人都遵循约定.在您无法访问 Internet 的情况下(我非常熟悉这种情况)，您的选择是在您在线时获取所有依赖项，然后可选择设置本地 Maven 存储库(如 Nexus 或 Artifactory)来发布这些工件.然后你告诉你的构建工具以及 Maven Central 等等.
4. Maven 使用 XML 进行配置，这在当时看起来非常酷.但是有两个后果.一是配置变得非常冗长.另一个是很难做定制的事情.您必须在 XML 中以声明方式执行所有操作，许多人发现这很痛苦.您可以在 XML 中配置插件，或者您自己编写并以 Maven 可以理解的方式包装它，并且可以在 XML 中进行配置.在代码中进行自定义构建要容易得多，也更强大.Gradle 为此选择了 Groovy，因为 Groovy 提供了很好的 DSL，并且对于来自 Maven 的 Java 开发人员来说非常容易学习.SBT 选择了 Scala，而 Leiningen 选择了 Clojure，因为这些构建工具针对这些语言/平台，因此，例如，Scala 开发人员除了 DSL 之外，无需学习任何新的东西即可使用 SBT.但更广泛的一点是，依赖代码而不是 XML 有很多好处.

1. Another critical function of build tools is to reduce "jar hell" by managing dependencies in a consistent way across builds. I just specify which version of Apache Commons or Google Guava or Spring or Jackson I want (or even range of versions) and the build tool will download them and put them somewhere so they can be in the classpath and in the build if applicable (like a war file). I can also define scopes--like I want this dependency to be available at compile time but this other one only at runtime. Do I need to provide it explicitly, or will it be available? Stuff like that.
2. This is Gradle specific. As described here, the Gradle wrapper helps teams run Gradle without having to manually install Gradle while also maintaining consistency. Everyone uses the same version. Once you set it up, you never have to worry about it, and all the Gradle tasks you want to use are available via the wrapper, so you need not even care that it's there. You can choose to install Gradle directly and run it directly, but I rarely see the point.
3. This is general. I mentioned dependency management earlier. In order to fetch these dependencies, the build tool needs to get online where they are available from Maven Central or a bunch of third-party repositories. Another Maven innovation adopted by the others is repository management, so compiled artifacts are published to a repository according to convention so other projects can use them. Usually, you don't care about that. You just tell the tool you need a certain dependency, and it knows how to grab it because everyone follows the conventions. In situations where you are without internet access (something I am quite familiar with), your options are to just grab all dependencies when you are online and then optionally to set up a local Maven repository like Nexus or Artifactory to publish those artifacts to. Then you tell your build tool to look there as well as Maven Central, etc.
4. Maven is configured with XML, and that seemed really cool at the time. But there are two consequences. One is the configuration becomes very verbose. Another is that it gets hard to do custom things. You have to do everything declaratively in XML, which many find to be a pain. You configure plugins in XML, or you write your own and wrap it in a way Maven can understand and can be configured in XML. It is a lot easier and more powerful to do custom build stuff in code. Gradle chose Groovy for this because Groovy makes for nice DSL's and is really easy to learn for Java developers coming from Maven. SBT chose Scala and Leiningen chose Clojure because those build tools target those languages/platforms, so a Scala developer, for example, doesn't have to learn anything new to use SBT besides the DSL. But the broader point is that relying on code rather than XML has a lot of benefit.

希望有所帮助.

这篇关于Gradle 的目的是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！