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

问题描述

我会用一些帮助理解背后摇篮的概念（插件v 0.7）的安卓0.4.0工作室的背景下。我没有用摇篮前，它引起了我什么，但问题。我没有看到它的目的/益处，因为我不知道有足够的了解它。

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?

什么是摇篮的包装？什么样的变化，如果有的话，它使已完成的应用程序？

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

为什么摇篮需要一直在线？我没有 就我个人的笔记本电脑上网时，我在工作。它得到 到我无法运行或测试我的应用程序的点，因为摇篮不能 解决无上网某些资源。

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.

为什么摇篮使用Groovy是很重要？我已经搜索 在互联网附近，而往往是一些人喜欢约 摇篮，但他们通常不解释为什么Groovy是重要或 它做什么的Andr​​oid应用程序。

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.

有时候这很难作为一个​​中级程序员的信息往往是过于简单或过于复杂。除了我的具体问题，你可以提供的任何其他信息将是有益的。我不希望辩论摇篮的利弊VS其他工具可以做同样的事情，我只是想更多地了解摇篮和它的使用，所以我可以作出明智的决定。

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.

感谢

推荐答案

您的一些问题是普遍的，因为它们为什么构建工具是一件好事，因为一般事项发言。其他人去专门摇篮。我会尽量尽量简洁地解决这两个类别，同时尽量避免别人的挑剔的术语。

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，摇篮，SBT，Leiningen等工具有助于自动化，我们原本需要手动执行或任务手动自动。我用后者来形容我以前做蚂蚁 - 编写自定义任务来编译，运行，生成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. 的构建工具的另一个重要功能是一致的方式在构建管理依赖，以减少罐地狱。我只是指定我想阿帕奇共享或谷歌番石榴或Spring或杰克逊的版本（甚至范围的版本）和构建工具将它们下载，​​并把他们的地方，使他们可以在类路径和编译如果适用（如一个war文件）。我还可以定义范围 - 就像我想这种依赖是在编译时间，但只有这另外一个在运行时。我是否需要明确提供它，还是会推出？这样的东西。
2. 这是具体的摇篮。如上所述这里的摇篮包装有助于运行摇篮团队，而无需手动安装摇篮，同时也保持一致性。每个人都使用相同的版本。一旦你设置它，您再也不必担心它，并通过包装可你想用所有的摇篮任务，所以你需要甚至不关心它的存在。您可以选择直接安装摇篮，并直接运行它，但我很少看到这一点。
3. 这是一般。我提到的依赖管理较早。为了获取这些依赖关系，构建工具需要上网了，他们可以从Maven的中央或一堆第三方仓库。通过别人的Maven的另一个创新是的资料库管理的，所以编译文物按照约定，以便其他项目可以使用它们发布到资源库。通常情况下，你不关心这个。你只告诉你需要一定的依赖性的工具，它知道如何抓住它，因为每个人都遵循的惯例。当你没有连接到Internet（这是我很熟悉的）的情况下，你的选择是只获取所有的相关性，当你在网上，然后有选择建立一个本地仓库如Nexus或Artifactory的发布这些文物。然后你告诉你的构建工具看起来有和Maven的中央，等等。
4. 在Maven的配置了XML，而且似乎真的很酷的时间。但有两个后果。一个是配置变得非常冗长。另一个原因是，它变得很难做定制的东西。你所要做的一切声明的XML，其中许多人发现是一个痛苦。您可以在XML配置的插件，或者你写你自己的，敷的方式Maven的可以理解，可以在XML配置。这是一个更容易和更强大的做自定义生成的东西，在code。摇篮选择Groovy的这个因为Groovy使得DSL很好的，是很容易学习Java开发人员从Maven的到来。 SBT选择Scala和Leiningen选择Clojure的，因为这些构建工具针对那些语言/平台，所以斯卡拉开发者，例如，没有学习任何新的使用SBT除了DSL。但更广泛的观点是，依靠code，而不是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.

希望有所帮助。

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