Here is a list of some of Gradle's features.
Gradleの特長は以下の通りです。
At the heart of Gradle lies a rich extensible Domain Specific Language (DSL) based on Groovy. Gradle pushes declarative builds to the next level by providing declarative language elements that you can assemble as you like. Those elements also provide build-by-convention support for Java, Groovy, OSGi, Web and Scala projects. Even more, this declarative language is extensible. Add your own new language elements or enhance the existing ones, thus providing concise, maintainable and comprehensible builds.
Gradleの核となっているのは、拡張性豊富なGroovyベースのDSLです。 それは、好きなように組み立てて記述できる、ビルド用の宣言型プログラミング言語とも言えるものであり、従来の宣言的なビルド記述をさらに上の段階へ推し進めます。 そのプログラミング言語には、JavaやGroovy、OSGi、WebそしてScalaなどのプロジェクトを一般的な方法でビルドする機能も備わっています。 さらに、このプログラミング言語はとても拡張性豊富なものです。 新たな言語機能を追加したり、既存の言語機能を拡張したりすることで、簡潔でメンテナンス性の良い、分かりやすいビルドシステムを作ることができるでしょう。
The declarative language lies on top of a general purpose task graph, which you can fully leverage in your builds. It provides utmost flexibility to adapt Gradle to your unique needs.
Gradleの提供する宣言型プログラミング言語は、グラフ構造をもつ汎用のタスク群の上に構築されています。 皆さんのビルドシステムには様々なニーズがあると思いますが、Gradleは、それらに適合できる、究極的な柔軟性を持っているのです。
The suppleness and richness of Gradle finally allows you to apply common design principles to your build. For example, it is very easy to compose your build from reusable pieces of build logic. Inline stuff where unnecessary indirections would be inappropriate. Don't be forced to tear apart what belongs together (e.g. in your project hierarchy). Avoid smells like shotgun changes or divergent change that turn your build into a maintenance nightmare. At last you can create a well structured, easily maintained, comprehensible build.
Gradleは柔軟性があり機能が豊富なので、ビルドを記述する際にプログラミングにおける一般的な設計の原則を適用できます。たとえば、ビルド用のロジックを利用可能な単位に細かく分割し、そのロジックを組み立ててビルドを構築することも簡単にできます。ロジックの呼び出しがむやみに複雑になってきたときはインライン化しましょう。同じプロジェクト階層に属しているなど、本来一カ所にあるべきロジックを、無理にいろんなところに書く必要もありません。変更が発散したり分岐したりして、ビルドのメンテナンスが悪夢に変わり果てるのを防ぎ、構造化されたメンテナンス性の良い分かりやすいビルドを記述できます。
From being a pleasure to be used embedded to its many hooks over the whole lifecycle of build execution, Gradle allows you to monitor and customize its configuration and execution behavior to its very core.
ビルドが実行されるライフサイクル全体に、たくさんのフックを埋め込むことができます。 なので、非常に深い部分までGradleの設定や振る舞いをモニタリングしたりカスタマイズしたりすることが可能です。
Gradle scales very well. It significantly increases your productivity, from simple single project builds up to huge enterprise multi-project builds. This is true for structuring the build. With the state-of-art incremental build function, this is also true for tackling the performance pain many large enterprise builds suffer from.
Gradleでは、ビルドの分割を強力にサポートしています。このことは、単純なシングルプロジェクトでもエンタープライズレベルの巨大なマルチプロジェクトでも生産性の大きな向上につながります。ビルドを構造化できますし、最先端のインクリメンタルビルドで、たくさんの大きなプロジェクトをビルドするときのパフォーマンスを改善することもできるからです。
Gradle's support for multi-project build is outstanding. Project dependencies are first class citizens. We allow you to model the project relationships in a multi-project build as they really are for your problem domain. Gradle follows your layout not vice versa.
Gradleは突出したマルチプロジェクトのサポートが特長です。プロジェクト間の依存関係はGradleのファーストクラス・オブジェクトであり、ごく普通に取り扱うことができます。世の中にはいろいろなビルドがありますが、Gradleではそれぞれのビルドに特有の問題点、課題にしたがってマルチプロジェクト、またプロジェクトの関係をモデリングできます。つまり、Gradleがあなたのプロジェクト構造に従うのであって、その逆ではありません。
Gradle provides partial builds. If you build a single subproject Gradle takes care of building all the subprojects that subproject depends on. You can also choose to rebuild the subprojects that depend on a particular subproject. Together with incremental builds this is a big time saver for larger builds.
Gradleでは部分ビルドが可能です。一つのサブプロジェクトをビルドすれば、Gradleはそのプロジェクトに依存しているすべてのプロジェクトもビルドします。また、依存しているプロジェクトのうち、どのプロジェクトを再ビルドするか選択することもできます。大きなプロジェクトの場合、これはインクリメンタルビルドと同様、大きな時間の節約になるでしょう。
Different teams prefer different ways to manage their external dependencies. Gradle provides convenient support for any strategy. From transitive dependency management with remote Maven and Ivy repositories to jars or directories on the local file system.
外部ライブラリの解決には、チームごとにさまざまな方法があるものです。リモートのMavenやIvyのリポジトリを使った推移的な依存関係の管理から、ローカルファイルシステム上のjarやディレクトリまで、どのような方法をとるにせよGradleはそれらを強力にサポートします。
Ant tasks are first class citizens. Even more interesting, Ant projects are first class citizens as well. Gradle provides a deep import for any Ant project, turning Ant targets into native Gradle tasks at runtime. You can depend on them from Gradle, you can enhance them from Gradle, you can even declare dependencies on Gradle tasks in your build.xml. The same integration is provided for properties, paths, etc ...
Gradleでは、Antのタスクはファーストクラス・オブジェクトです。さらにおもしろいことに、Antのプロジェクトもまたファーストクラス・オブジェクトなのです。Gradleでは、Antプロジェクトをインポートして、実行時にAntのターゲットをGradleネイティブのタスクへ変換できます。もちろんインポートしたタスクへの依存関係を定義できますし、拡張もできます。それどころか、build.xmlの中でGradleのタスクへの依存関係を宣言することさえ可能です。プロパティやパス、その他諸々についても同じレベルで統合されています。
Gradle fully supports your existing Maven or Ivy repository infrastructure for publishing and retrieving
dependencies. Gradle also provides a converter for turning a Maven pom.xml into a Gradle script.
Runtime imports of Maven projects will come soon.
Gradleは、既存のMaven/Ivyリポジトリのインフラ、依存関係の定義や解決といった機能を完全にサポートしています。さらに、Mavenのpom.xmlをGradleのスクリプトに変換するコンバーターも用意されています。実行時にその変換を行う機能も近いうちに提供される予定です。
Gradle can adapt to any structure you have. Therefore you can always develop your Gradle build in the same branch where your production build lives and both can evolve in parallel. We usually recommend to write tests that make sure that the produced artifacts are similar. That way migration is as less disruptive and as reliable as possible. This is following the best-practices for refactoring by applying baby steps.
Gradleは、どんな構造のプロジェクトにも適用できます。なので、今製品のビルドを行っているブランチがあるなら、それと同じブランチ上で平行してGradleのビルドを開発していくことができます。私たちは常より、成果物を作成するときには、いつもと同様のものができているか確認するようなテストを書くことを推奨していました。この方法で移行すれば、既存のものを破壊するような可能性は少ないし、可能な限りの安全性を確保できます。これは、小さな変更を積み重ねていくという、リファクタリング上のベストプラクティスなのです。
Gradle's build scripts are written in Groovy, not XML. But unlike other approaches this is not for simply exposing the raw scripting power of a dynamic language. That would just lead to a very difficult to maintain build. The whole design of Gradle is oriented towards being used as a language, not as a rigid framework. And Groovy is our glue that allows you to tell your individual story with the abstractions Gradle (or you) provide. Gradle provides some standard stories but they are not privileged in any form. This is for us a major distinguishing feature compared to other declarative build systems. Our Groovy support is not just sugar coating. The whole Gradle API is fully Groovy-ized. Adding Groovy results in an enjoyable and productive experience.
GradleのビルドスクリプトはXMLではなくGroovyで記述します。しかし、それは単純に動的言語のスクリプト機能を生で使わせるということではありません。それではビルドのメンテナンスがむやみに難しくなるだけです。Gradleは、硬直したフレームワークとしてではなく、一つの言語として使用されることを想定してデザインされています。Groovyは、Gradle(またはあなた自身)が提供する抽象性と個々のビルドがもつ独自の筋書きとをくっつける接着剤となっているのです。Gradleでは、いくつかの標準的なビルドの筋書きを用意していますが、それら筋書きが何かの特別な扱いを受けているというわけではありません。別のビルドシステムと比較したとき、このことはGradleの主な特徴の一つになると考えています。GradleのGroovyサポートはただの構文糖衣ではありません。すべてのAPIは完全にGroovy化されていて、楽にGroovyを使うことができ、生産性を向上させています。
The Gradle Wrapper allows you to execute Gradle builds on machines where Gradle is not installed. This is useful for example for some continuous integration servers. It is also useful for an open source project to keep the barrier low for building it. The wrapper is also very interesting for the enterprise. It is a zero administration approach for the client machines. It also enforces the usage of a particular Gradle version thus minimizing support issues.
Gradleラッパーを使うと、Gradleをインストールしていないマシンでビルドを実行できます。たとえば、CIサーバー上でビルドしたり、オープンソースプロジェクトを簡単にビルドできるようにしたりするのに便利です。また、これはクライアントマシンの管理維持作業を省く(zero administration)というアプローチでもあり、企業向けと考えてもとても面白いものだといえます。使用させるGradleのバージョンを固定し、サポートしなければならないような問題の発生を最小限に抑えることもできます。
Gradle is an open source project, and is licensed under the ASL.
Gradleはオープンソースプロジェクトであり、ASLのもとで公開されています。
We think the advantages of an internal DSL (based on a dynamic language) over XML are tremendous when used in build scripts. There are a couple of dynamic languages out there. Why Groovy? The answer lies in the context Gradle is operating in. Although Gradle is a general purpose build tool at its core, its main focus are Java projects. In such projects the team members will be very familiar with Java. We think a build should be as transparent as possible to all team members.
ビルドスクリプトを記述するということを考えたとき、XMLに対する内部DSL(動的言語ベース)のアドバンテージというのは途方もなく大きいものです。 ただ、動的な言語はいくつかあるのに、なぜGroovyなのでしょうか。 その答えは、Gradleが想定しているシチュエーション、環境にあります。 Gradleは本質的に言えば一般的な利用が可能な汎用のビルドツールですが、メインとしてフォーカスしているのはJavaのプロジェクトです。 そのようなプロジェクトの場合、チームのメンバーがJavaに習熟しているのは明らかでしょう。 私たちは、ビルドはすべてのチームメンバーに対してできるだけ分かりやすいものであるべきだと考えています。
In that case, you might argue why we don't just use Java as the language for build scripts. We think this is a valid question. It would have the highest transparency for your team and the lowest learning curve, but because of the limitations of Java, such a build language would not be as nice, expressive and powerful as it could be. [1] Languages like Python, Groovy or Ruby do a much better job here. We have chosen Groovy as it offers by far the greatest transparency for Java people. Its base syntax is the same as Java's as well as its type system, its package structure and other things. Groovy provides much more on top of that, but with the common foundation of Java.
それならGroovyでなくJavaを使えばいいのにと思われるかもしれません。それはもっともな疑問です。 ビルド用の言語にJavaを使えば、開発チームにとって最高に分かりやすく、学習曲線が最小限緩やかなビルドとなるでしょう。 しかし、Javaはビルド用の言語として使うには表現力や機能に限界があるのです。 [2] このような用途には、PythonやGroovy、Rubyのような言語の方が向いています。 私たちは、Java世界の住人にとって断然飛び抜けた分かりやすさを提供するGroovyを選択しました。 Groovyの文法は、型システム、パッケージ構造、その他諸々についてJavaをベースにしています。Groovyはその上に様々な機能を構築していますが、土台はJavaと同じなのです。
For Java developers with Python or Ruby knowledge or the desire to learn them, the above arguments don't apply. The Gradle design is well-suited for creating another build script engine in JRuby or Jython. It just doesn't have the highest priority for us at the moment. We happily support any community effort to create additional build script engines.
Javaの開発者であっても、PythonやRubyの知識を持っていたり、それらを楽しく学んでいるのなら上記の議論は当てはまりません。 Gradleはビルドスクリプト・エンジンとしてJRubyやJythonを使えるよう適切にデザインされています。 私達にとって、目下のところはそれらの優先度は高くありませんが。 私たちは、そういった追加のビルドスクリプトエンジンを作っていただけるあらゆるコミュニティを喜んでサポートします。
[1] At http://www.defmacro.org/ramblings/lisp.html you find an interesting article comparing Ant, XML, Java and Lisp. It's funny that the 'if Java had that syntax' syntax in this article is actually the Groovy syntax.
[2] http://www.defmacro.org/ramblings/lisp.htmlに、AntとXML、Java、Lispを比較している興味深い記事が載っています。 「もしJavaがこの文法を持っていたら」という前提で書かれている構文が、まさにGroovyの文法になっているのが面白いところです。