追記1: コメントでの指摘を受け、gvmに関する記述を削除
この記事は、日経ソフトウェア 2013年 06月号 04/24発売 のステマ記事です。
6月号に、@keiji_ariyama(前座部分担当) と 僕(Gradle概要担当) と @sys1yagi(Android対応部分担当) という分担でGradle入門的な記事を書きました。
ですが、僕の目的としてはトップゲート社員への布教を主目的と考えて書いたため、本来要求されている分量を(わざと)大幅にオーバーして書いていました。雑誌に掲載されなかった溢れ分をネットで公開して良いか打診した所、「全文掲載でも良いですよ」という豪気なお許しを頂いたのでここに公開します。この場を借りてお礼申し上げます。
プロの編集さんの手を経て、だいぶわかりやすく噛み砕かれたものが雑誌のほうには掲載されていますので、ここに書いてある内容が難しいなぁ…と思ったら是非雑誌の方を手に取ってみてください。
また、僕が担当している箇所以外の、「何故Gradleが必要か」とか「AndroidとGradleを組み合わせるには？」について知りたい人は同じく雑誌を手にとってみてくださいｗ
なお、執筆時は 3/25 とかで、1.4が最新でした。今は1.5が出ています。
Gradleとは？
ビルドシステム、ひいてはGradleがあると助かる場面とは、一体どういう場面でしょうか？
筆者の具体例でいうと、ある日上司がやってきて、「今お前たちが作っているアプリを俺の端末にインストールしてくれ。」と言ってくるわけですね。1回だけならば話しは簡単です。
PCと端末をmicroUSBで接続して、Eclipseを起動してADTでアプリをコンパイルして、端末に転送してインストールして返してあげるだけです。
ですが、それが2回も3回も…となってくると、思わず「自分でやってください！＞＜」と言ってしまいたくなりますが、上司のPCには開発環境が整っていません。それに、新しいAndroidのSDKがリリースされたら上司のPCの環境を更新する作業をやってあげなければいけません。しかし、僕はそんな面倒くさいことは引き受けたくありません！
そこで、登場してくるのがビルドシステムです。今のAndroidの標準のビルドシステムではantが使われています。antでも、「このバッチファイルを叩いたら勝手にアプリが端末に入りますから！＞＜」ぐらいまでは持っていけます。ですが、Android SDKのインストールやantのセットアップはやらなければいけません。これだけでもだいぶ楽になりましたが、今一歩というところですね。
もし、Gradleであれば、Gradle自身のダウンロードもGradleにやらせることができますし、Android SDKのダウンロードも気合を入れればさせることができるでしょう。また、GUIで操作することもできるので、上司にソース一式を渡して「自分でやってください！＞＜」で済ませることもできるようになるでしょう。
ここまでできれば、格段に楽になったといっても納得でしょう。
さて、ここからは一般的なお話です。ちまたには、色々なビルド方法があふれています。Makeだとか、Antだとか、Mavenだとか色々です。自分で書いたことがないまでも、利用したことさえない、という人は滅多にいないでしょう。
Makefileは利用できるプラットフォームを選びます。また、その自由度の高さ故にプロジェクト毎に共通の使い方というものが決められているわけではありません。
Antは柔軟で便利なのは良いのですが、Makefileと同じように自由度が高く、さらに記述もXMLで書かなければいけないため、慣れるまでが大変です。また、ライブラリの依存関係の管理や追加などは行う機能はないためチームで開発する時にみんなの環境を併せるのに苦労します。
Mavenは依存関係の管理や追加もできますが、理解するまでに多くの事を理解しなければならず、またXMLで全ての設定を行わなければいけないため習得の難易度が高く、いわゆる"ビルド職人"と呼ばれるような特定の個人に依存せざるをえない状態でした。
そこで、登場してきたのがGradleです。Gradleは設定をGroovyと呼ばれるJVM上で動くスクリプト言語で書きます。
Groovyで書かれた設定ファイルはXMLよりも可読性が高く、処理の自由度も大変高いです。依存関係の管理も行うことが出来ます。チームで仕事をするために便利な機能もよく考えられて作られていて、大変便利です。今後開発を行なっていく上で無くてはならない存在になっていくでしょう。そのために、まずはあなたがGradle職人になってみるのも良いと思います。
Gradleが行なっている工夫については後々紹介していきます。
その他のセールスポイントとして、ドキュメントが非常に充実していて優れていることがあげられます。公式の英語のドキュメントのみならず、和訳のドキュメントも大変充実していて、これを拾い読みするだけでGradleの事がかなりたくさんわかってきます。
残念な所を無理に上げると、Mavenのpluginとの互換性がないため、熱心なMavenユーザ(筆者の事です)からすると、今までの環境を一部捨てざるをえないことは少しつらいですね。
Gradleのインストール
方法1 古き良き方法を使う
http://www.gradle.org/ Gradle公式サイトのDOWNLOADSリンクから最新のGradleを落としてきましょう。
gradle-1.4-bin.zip を解凍し、適当な所に置きます。解凍したフォルダを環境変数GRADLE_HOMEにそのパスを設定します。また、GRADLE_HOME/binにパスを通しておきます。
方法2 gvmを使う
追記1による修正: https://gradle.org/install/ を見て、SDKMANなどを使ったほうがよいでしょう。
Groovy enVironment Manager(GVM)を使うのが古き良き方法より、優れているでしょう。可能であればこちらを使うことをオススメします。
動作確認
gradle -versionを実行してみて、Gradle 1.4がインストールされた事が確認できれば成功です。
------------------------------------------------------------
Gradle 1.4
------------------------------------------------------------
Gradle build time: Monday, January 28, 2013 3:42:46 AM UTC
Groovy: 1.8.6
Ant: Apache Ant(TM) version 1.8.4 compiled on May 22 2012
Ivy: 2.2.0
JVM: 1.7.0_17 (Oracle Corporation 23.7-b01)
OS: Mac OS X 10.8.3 x86_64
Gradleを使ってみよう
Gradleを使うと何が出来るの？
まずは、Gradleを使ってみましょう。Gradleではタスクという作業の固まりを作って、それを動かすことで仕事をこなして行きます。
最終的には「Androidのソースをコンパイルして、必要があればJUnitを動かして、端末にアプリをインストールする」とか、「無料版と有料版の2バージョンをリリースしているアプリのコンパイルを自動化し2つのapkを作成する」などの複雑な作業をこなすことが出来るようになるでしょう。(yagiさんパートにぶん投げ)
通常は、他の人が作った便利なタスクを借りて実行させます。そのため、ほんのすこしの記述をしておくだけで、手作業でするとしたらかなりの時間がかかる作業も何度でも繰り返し行わせることができるようになります。もし、「アプリをコンパイルする前にバージョン番号を書き換えたい…」という時は、自分で追加のタスクを書く必要があります。
Gradleを使ってみよう
まずは簡単なタスクを定義する所から初めてみましょう。最終的には他のタスクに自分の好きな処理を追加できるところまで行きましょう。
以下のファイルを作成し、同じフォルダでgradle helloWorldを実行してみます。短縮して、gradle hWやgradle hellを実行しても同じ結果が得られます。gradleではタスクの名前が一意になる程度に短縮してもよしなに計らってくれます。便利ですね。(gradle heなどを実行するとgradle helpが実行されてしまいます。さもありなん。)
task helloWorld << {
println "Hello, world!"
}
実行結果
:helloWorld
Hello, world!
BUILD SUCCESSFUL
Total time: 4.648 secs
新しく定義したhelloWorldタスクが実行され、"Hello, world!"が表示されました。
何が起こっているか簡単に説明しましょう。task helloWorldで新しいタスクを定義し、{}部分が処理を行うクロージャになっています。Gradleの記述言語であるGroovyでは演算子の定義を書き換えることができます。<<はleftShiftメソッドの呼び出しになります。
このコードを少し書き換えるとこのようになります。
task helloWorld {
doLast {
println "Hello, world!"
}
}
実行してみると、同じ結果になりますね。<<は、doLastと同じ意味合いになります。もし、<<もdoLastもなしにするとどうなるでしょうか？試してみましょう。
task helloWorld {
println "Hello, world!"
}
これに対して、gradle tasksを実行してみます。tasksは、利用可能なタスクの一覧を表示してくれるプリインのタスクです。
Hello, world!
:tasks
------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------
Help tasks
----------
dependencies - Displays all dependencies declared in root project 'helloworld3'.
dependencyInsight - Displays the insight into a specific dependency in root project 'helloworld3'.
help - Displays a help message
projects - Displays the sub-projects of root project 'helloworld3'.
properties - Displays the properties of root project 'helloworld3'.
tasks - Displays the tasks runnable from root project 'helloworld3' (some of the displayed tasks may belong to subprojects).
Other tasks
-----------
helloWorld
To see all tasks and more detail, run with --all.
BUILD SUCCESSFUL
Total time: 0.884 secs
おや？一番先頭にhelloWorldタスクが実行されてしまっている様が見て取れます。
doLastを使わない部分は、タスクの設定などを行う箇所になるのですね。doLastを使う書き方に戻してみましょう。
task helloWorld {
description = "こんにちは！します。"
doLast {
println "Hello, world!"
}
}
結果を見てみましょう。
:tasks
------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------
中略
Other tasks
-----------
helloWorld - こんにちは！します。
後略
helloWorldタスクは実行されなくなっていますね。代わりにタスクの概要が表示されるようになりました。descriptionとして設定した内容ですね。このように、タスクの設定を行う箇所とすると良いでしょう。
Gradleの自由さよ
さて、そろそろGradleの本気を発揮してまいりましょう。GradleはGroovyという言語で記述しなければならないのですが、ぶっちゃけJavaのコードはGroovyのコードとしても正しいのです。そのため、まずは必要最低限のGradleが使える程度の勉強だけして、大部分をJavaコードで補うというのも手です。
import org.json.JSONObject;
buildscript {
repositories { mavenCentral() }
dependencies { classpath 'org.json:json:20090211' }
}
task weatherReport {
description = "今日の東京のお天気をお伝えします"
doLast {
// Livedoorのお天気情報APIを利用してJSON形式のデータを取得する
URL url = new URL("http://weather.livedoor.com/forecast/webservice/json/v1?city=130010");
URLConnection connection = url.openConnection();
InputStream is = connection.getInputStream();
BufferedReader reader = new BufferedReader(new InputStreamReader(is));
JSONObject json = new JSONObject(reader.readLine());
String cityName = json.getJSONObject("location").getString("city");
String weather = json.getJSONArray("forecasts").getJSONObject(0).getString("telop");
println "${cityName}の今日のお天気は${weather}です！"
}
}
実行してみましょう。
$ gradle wR
:weatherReport
東京の今日のお天気は晴のち曇です！
BUILD SUCCESSFUL
Total time: 2.009 secs
うーむ！素晴らしい自由度！タスクの中でWebサービスにアクセスして今日の天気を調べて表示することもできてしまいました。
GroovyではJavaよりも多くのpackageがデフォルトでimportされているため、java.io.InputStreamやjava.net.URLをimportせずとも済んでいます。( 参考 http://groovy.codehaus.org/Differences+from+Java )
その他の目新しい点として、buildscriptが増えた事でしょうか。ここでは、build.gradle中で使うライブラリの設定を行なっています。MavenのCentralリポジトリを依存性解決のために利用し、json.orgのライブラリを利用するように設定しています。
MavenのCentralリポジトリには色々な人が作った多大な資産が眠っているため、是非活用してみましょう。
http://search.maven.org/ で検索すると、色々と出てきます。筆者が出しているライブラリもnet.vvakameで検索するといくつか出てきます。(宣伝)
さて、これでJavaで出来る範囲であれば、なんであれ自分でオリジナルタスクを作ってどうとでもできそうな気がしてきました。例えば、ファイルのコピーだとかクリーンアップなど、色々と出来そうです。
GradleとGroovyには様々な便利メソッドやタスクがあるので、慣れてきたら自分で調べて裾野を広げていけると良いでしょう。
Javaのプロジェクトをビルドできるようにしよう
さて、Gradleで天気予報を表示するのもなかなか便利かもしれませんが、ビルドツールとしての本領を発揮してもらうことにしましょう。ここでは、多くの読者の環境とマッチするであろう、Java+Eclipseでの開発環境を整えてみます。
apply plugin: "java"
apply plugin: "eclipse"
repositories {
mavenCentral()
}
dependencies {
testCompile "junit:junit:4.11"
}
これだけ！簡単ですね。Gradleにはプラグインという仕組みがあり、複数のタスクを追加してくれたりします。ここではjavaとeclipseを追加しています。これだけで、非常に多くの物事をこなしてくれるようになります。
あとはrepositoriesとdependenciesですね。お天気予報タスク作成の段では、build.gradleで利用するためにjson.orgのライブラリを追加したのでした。一方、こっちではUnitTestを書くために、開発プロジェクトで使うためにJUnitへの依存することを追加しました。
さて、次はJavaコードを書いてみましょう。下準備として、src/main/java フォルダと src/test/java フォルダを手作業で作っておきます。その後でgradle eclipseを実行すると、Eclipseにプロジェクトをimportできるようにするためのメタファイルが生成されます。もちろん、build.gradleで設定したJUnitへの依存関係もちゃんと考慮され、Maven CentralリポジトリからJUnitのjarファイルを自動的にダウンロードしてEclipse上でもビルドパスに追加してくれます。
さくさくとJavaコードを追加してみます。
public class Sample {
public static void main(String[] args) {
Sample sample = new Sample();
System.out.println(sample.getMessage());
}
public String getMessage() {
return "Sample!";
}
}
import static org.hamcrest.CoreMatchers.*;
import static org.junit.Assert.*;
import org.junit.Test;
public class SampleTest {
@Test
public void test() {
Sample sample = new Sample();
assertThat(sample.getMessage(), is("Sample!"));
}
}
試しに、Eclipse上でプロジェクトを右クリック→Run as→JUnit Testを選択してテストを走らせてみます。おそらく、緑になったことでしょう。素晴らしい！
次に、gradle上でもテストを動かしてみます。gradle testでテストが実行できます。
$ gradle test
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava
:processTestResources UP-TO-DATE
:testClasses
:test
Picked up _JAVA_OPTIONS: -Dfile.encoding=UTF-8
BUILD SUCCESSFUL
Total time: 2.284 secs
テストが走って、完走したようです。念の為にわざとテストを失敗させてみます。
$ gradle test
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava
:processTestResources UP-TO-DATE
:testClasses
:test
SampleTest > test FAILED
java.lang.AssertionError at SampleTest.java:11
1 test completed, 1 failed
:test FAILED
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':test'.
> There were failing tests. See the report at: file:///Users/vvakame/Dropbox/work/docs/nikkei-software-2013-06-gradle/sample/javaProject1/build/reports/tests/index.html
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.
BUILD FAILED
Total time: 2.156 secs
よしよし、良い感じですね。これでJavaプロジェクトをGradleで管理できるようになりました。
AndroidのプロジェクトをEclipseで開発できるようにしてみよう(序章)
(Android公式のやり方とは違います。公式のやり方はyagiさんパートを参照。)
さて、この記事の後半ではyagiさんがGradle+Android開発の方法を紹介してくださいますが、ここではGradleのAndroid Pluginを使わずに無理矢理EclipseでAndroid開発が出来るようにしてみます。
まず、ざっくりとEclipse自体の説明を行います。Eclipseはプロジェクトに対して、いくつか設定ファイルを持ちます。代表的なのは、プロジェクトの設定が書いてある.project、プロジェクトのビルドパスが書いてある.classpath、Java開発用プラグインの設定ファイルである.settings/org.eclipse.jdt.core.prefsなどです。
要は、それらファイルをgradle eclipseした時に生成してやれば良いわけです。
まずは、Gradle関係なくADTのWizardで普通にAndroidプロジェクトを生成し、どういう設定ファイルか確認してみます。そして、その結果を再現してみます。
<?xml version="1.0" encoding="UTF-8"?>
<projectDescription>
<name>AndroidProject</name>
<comment></comment>
<projects>
</projects>
<buildSpec>
<buildCommand>
<name>com.android.ide.eclipse.adt.ResourceManagerBuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>com.android.ide.eclipse.adt.PreCompilerBuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>org.eclipse.jdt.core.javabuilder</name>
<arguments>
</arguments>
</buildCommand>
<buildCommand>
<name>com.android.ide.eclipse.adt.ApkBuilder</name>
<arguments>
</arguments>
</buildCommand>
</buildSpec>
<natures>
<nature>com.android.ide.eclipse.adt.AndroidNature</nature>
<nature>org.eclipse.jdt.core.javanature</nature>
</natures>
</projectDescription>
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
<classpathentry kind="src" path="src"/>
<classpathentry kind="src" path="gen"/>
<classpathentry kind="con" path="com.android.ide.eclipse.adt.ANDROID_FRAMEWORK"/>
<classpathentry kind="con" path="com.android.ide.eclipse.adt.LIBRARIES"/>
<classpathentry kind="output" path="bin/classes"/>
</classpath>
なるほど。こんな感じですね。通常のJavaプロジェクトとくらべてみると、ビルドコマンドが3つ(javabuilder以外)と、ネイチャーが1つ(AndroidNature)が追加されているようです。また、クラスパスにソースフォルダとしてgenフォルダが追加され、JREコンテナが削除され、代わりにAndroidのフレームワークとライブラリが追加されています。また、コンパイル後のアウトプットフォルダがbin/classesとなっています。
また、AndroidのサポートしているJavaのバージョンが5と6だけなので、そのための設定も追加する必要がありそうです。AndroidもはやくJava7対応してほしいですね。7はまだいいとして、8が来なかったら発狂してオワコン扱いし始めますよ僕は。invokeDynamicのサポートとかdalvikの改修もめんどくさいし色々な機種にそれを反映させていくのにも時間がかかるのだから段階的に進めていってほしいものです。古い環境でコードを書かされる事を喜ぶエンジニアはいないのですよ！
それでは、build.gradleを書いてみましょう。Androidの場合はライブラリの追加は、普通のJavaプロジェクトと同じようにやるのではなく、libsフォルダにjarを入れることで行いますね。そのため、dependenciesでcompile "com.google.android:support-v4:r7"などとやってしまうわけには行きません。そのため、androidLibsを作成して独自に依存関係の管理をしてやるようにします。dependenciesでの記述ではそちらを使います。また、libsフォルダに依存ライブラリをコピーするためにcopyDependenciesToAndroidLibsタスクを作成し、gradle eclipseが実行された時に依存関係が勝手にlibsフォルダに入るようにしてやります。ついでに、cleanタスクでlibsフォルダを綺麗にするようにしてやります。
また、.classpathと.projectファイルの生成もeclipseに追加の設定を行い、望む物が生成されるようにしてやります。
apply plugin: "java"
apply plugin: "eclipse"
sourceCompatibility = 1.6
targetCompatibility = 1.6
repositories { mavenCentral() }
configurations { androidLibs }
dependencies {
androidLibs "com.google.android:support-v4:r7"
androidLibs "com.googlecode.android-query:android-query:0.24.3"
}
sourceSets {
main {
java.srcDirs "src", "gen"
output.classesDir = "bin/classes"
}
}
task clean(overwrite: true) { delete "libs" }
task copyDependenciesToAndroidLibs(type: Copy) {
into "libs"
from configurations.androidLibs
eclipseJdt.dependsOn copyDependenciesToAndroidLibs
}
eclipse {
project {
name = 'AndroidProject'
natures 'com.android.ide.eclipse.adt.AndroidNature'
buildCommand 'com.android.ide.eclipse.adt.ResourceManagerBuilder'
buildCommand 'com.android.ide.eclipse.adt.PreCompilerBuilder'
buildCommand 'com.android.ide.eclipse.adt.ApkBuilder'
}
classpath {
containers.clear();
containers 'com.android.ide.eclipse.adt.ANDROID_FRAMEWORK', 'com.android.ide.eclipse.adt.LIBRARIES'
downloadSources = true
downloadJavadoc = true
}
}
今回のbuild.gradleではbuildは行わないので、これで十分でしょう。gradle eclipseでAndroid開発用の設定ファイルが生成されるようになりました。
antの代わりに
現在、antを使っているプロジェクトがGradleに移行してくるのもなかなか簡単です。やってみましょう。
<?xml version="1.0" ?>
<project name="AntSample">
<target name="roll">
<script language="javascript">
<![CDATA[
// 6面ダイスを2個ふり、合計値を表示する
var dice = Math.ceil(Math.random() * 6) + Math.ceil(Math.random() * 6);
var echo = AntSample.createTask("echo");
echo.setMessage("2D6: " + dice);
echo.perform();
]]>
</script>
</target>
</project>
ant.importBuild 'build.xml'
task rollBefore {
doLast {
println "ダメージ計算を行います。"
}
roll.dependsOn rollBefore
}
task rollAfter(dependsOn: roll) << {
ant.echo "ダメージロールの結果をHPから引いてください。"
}
実行してみます。
$ gradle rollAfter
:rollBefore
ダメージ計算を行います。
:roll
[ant:echo] 2D6: 11
:rollAfter
[ant:echo] ダメージロールの結果をHPから引いてください。
BUILD SUCCESSFUL
Total time: 1.49 secs
うまくいったようです。既存のantの設定ファイルをant.importBuildでインポートするとantのタスクがそのままgradleのタスクとして利用できるようになります。本来のgradleタスクと同様に扱うことができます。ここでは、rollBeforeタスクをGradle側で定義し、Ant側タスクであるrollに依存するように設定しています(roll.dependsOn rollBefore部分)。
また、rollAfterタスクも定義し、rollタスクとの依存関係を定義しています。このため、rollAfterはrollに依存し、rollはrollBeforeに依存しているため、rollAfterを実行するとrollBefore→roll→rollAfterの順で実行されました。
gradle rollで上記と同じ結果を得たい場合はrollAfterの代わりに以下のよう書いてrollタスクのdoLastの処理をにすることもできます。
roll << {
ant.echo "ダメージロールの結果をHPから引いてください。"
}
また、rollAfterタスクの中で使っているように、antのechoタスクを利用しています。既にantに便利なものがあるのであればさくさく使ってしまい、徐々に移行していくのも良いでしょう。筆者はantのjavacタスクを利用し、AnnotationProcessorによるJavaコードの前処理を行ったりしています。
Mavenの代わりに
antがとっても簡単にとりあえず移行できたのと対照的に、MavenユーザがGradleに移行するにはあんまり便利なパスが用意されていません。
既存のMaven PluginはGradleと互換性がないため、既存の資産は使うことができません。Maven Centralリポジトリを利用して依存性の解決はできるので楽なんですけどね。
筆者は普段の開発にGoogleAppEngine/Javaを多用しております。そのためのフレームワークとしてSlim3を利用し、サーバ側からクライアント側へのデータのやり取りのために筆者作のJSON処理ライブラリであるJsonPullParserを利用しています。
GradleのEclipse pluginさんはかなり柔軟で、ご覧のとおりEclipse用設定ファイルをかなり柔軟に弄る事ができます。このbuild.gradleでは.settings/org.eclipse.jdt.core.prefsを弄るパートがproperties.setPropertyを連発することになりあまり美しくないですね。処理後に手書き処理で無理矢理差し替えてしまったほうが綺麗に行きそうです。
よりGradleが便利になる設定・使い方
ここからは、更にGradleを幸せに使える方法を紹介していきます。
gradle --daemon について
さて、Gradleを使っていると不満に思えてくるのが、実行時間の遅さです。なにせ、筆者の環境では先のJavaプロジェクトでgradle testすると実行に4.732秒ほどかかります。少し、長いなと感じますね。
その不満を解消するために、gradleには裏で常に待機していてもらうモードがあります。それが--daemonオプションです。
試しにgradle --daemon testとしてみましょう。1回目は裏で待機していないため、やはり5秒くらいかかりますがもう一回実行してみると、1.041秒というごく短時間でタスクを完了することができます。うーん、素晴らしい！
毎回毎回 --daemon とつけるのもメンドクサイので、GRADLE_OPTS環境変数に-Dorg.gradle.daemon=trueをセットすると、デフォルトでdaemonを使ってくれるようになります。
動いているdaemonを止めたい時や、一時的に使いたくない時のためにそれぞれ--stopや--no-daemonオプションが用意されています。
gradle wrapper について
さて、Gradleを導入したい！と思っても、チーム全員の開発環境をGradle用に整えて全員で歩調を併せて…といったことを考えるととたんに腰が重くなるものです。しかし、Gradleならその点簡単に解決できます。
gradle wrapperという仕組みが用意されていて、チームの中でGradleをマジメにインストールするのは貴方1人、それ以外の人はsvnやgitのリポジトリにコミットされているファイルだけ使えばOK！という塩梅にすることができます。
見てみましょう。
apply plugin: "java"
apply plugin: "eclipse"
repositories {
mavenCentral()
}
dependencies {
testCompile "junit:junit:4.11"
}
task wrapper(type: Wrapper) {
gradleVersion = '1.4'
}
task wrapper の記述が増えていますね。この記述を増やした後に gradle wrapperを実行します。
そうするとgradlew(Mac, Linux用)とgradlew.bat(Windows用)とgradleフォルダが生成されます。これらをリポジトリにコミットするようにします。すると、他の人達はgradleコマンドの代わりにgradlewを使えるようになります。gradlewを実行すると、もし必要であればgradleコマンド実行用のバイナリを勝手にダウンロードしてくれます。
まとめると、「みんな！gradleを使うためにはgradlewを使ってくれればOKだから！」と宣言すれば、すぐにチーム全員で使いはじめることが出来るようになるということです。
gradle --gui について
いやいや、gradlewは確かに嬉しいけど、gradlew eclipseとか、gradlew testとか、みんなに覚えされるのは大変だよ…！という意見もあるかもしれません。
ご安心ください！gradleにはなんとGUIモードも用意されているのです。試しに、gradle --guiまたはgradlew --guiを実行してみてください。
おぉ！素晴らしい！実行可能なタスクの一覧のウィンドウが表示され、マウスでもって好きなタスクを実行することができます。
あとは、gradlew --guiを実行してくれるバッチファイルでも置いておいて、それをダブルクリックするように教えればよいですね。お気に入りタスクを登録することもできるので、よく使うタスクを教えてあげると良いでしょう。
これで、みんなに簡単にgradleを使ってもらうことができますね :)
Gradleの記述環境
codehausによるGroovy Eclipseプラグインを利用するか、IntelliJ IDEAを利用すると良いでしょう。
筆者は本稿執筆のために、Groovy Eclipseプラグインをインストールして、build.gradleをGroovy Editorで編集しています。
参考書籍・資料について
英語の本ですが、毛虫本が大変良い資料になるでしょう。僕もこの記事を読むためにコードの部分を拾い読みするとかしましたが、大変参考になりました。