なぜEGradleを選ぶのか？
Gradle IDE pack(STS Gradle plugin)
Eclipse上でgradleを使用する場合、プラグインとしてGradle IDE pack(STS Gradle plugin)を長年使用してきたのだが、非常に具合がよろしくない。
例えば、あるプロジェクトAで作業中に、別のプロジェクトBを開くと、BのみならずAのビルドパスを変更してしまうようで、再度コンパイルがかけられたり、ひどいときにはAのライブラリが見つからなくなりエラー状態になってしまう。
buildship
STSは開発が継続されず、後継はbuildshipとのことで、こちらを試してみたのだが、これも気に入らない。例えば、build.gradleに以下のように記述するとする。
sourceSets {
main {
java {
srcDir 'src'; exclude '**/*Test.java';
}
resources {
srcDir 'src'; exclude '**/*Test.java';
}
}
}
これは、buildのときにだけ*Test.javaというクラスを除外することを意図しているのだが、なぜかbuildshipはEclipseのBuild PathのSourceに「Excluded **/*Test.java」という記述を入れてしまう。開発環境からも*Testクラスが見えなくなってしまうのだ。buildshipではこういった余計なお世話が多すぎる。build.gradleに記述されたとおりにEclipseの環境を変更しようとしてしまうのだ。
コマンドプロンプト
どちらも気に入らないので、しばらくコマンドプロンプトを使用していた。単純にEclipseからcmd(Windowsの場合）を起動して、その中でgradle.batを起動するだけである。
まずは、gradle.batにパスを通し、どこからでも実行できるようにする。
Eclipseのexternal toolに以下の設定を行う。
- Location: C:\Windows\System32\cmd.exe
- Working Directory: ${workspace_loc:/myProject}
- Common タブでencodingをMS932に
これで、この外部ツールを起動するとWindowsのコマンドプロンプトになるので、あとは
gradle build
などと打ち込めばよい。
EGradle
しかし、上記も疲れるので、探したところ、折衷案のようなEGradleというプラグインが見つかる。これを使用することにした。
このプラグインは、基本的にSTSやbuildshipのようにEclipseの環境に手を出すことはしない。私がこれらのプラグインに最も求めるところというのは、dependenciesを自動的にBuild Pathに入れてくれることなのだが、EGradleはそれさえもやってくれない。
–> これ間違い。dependenciesを自動でBuild Pathに入れる機能がある。GraldeのEclipseプラグインを使えばよい。本サイトでも説明している。
基本的にコマンドプロンプトを使うよりは、なんぼか楽というところである。