ラベル Gradle の投稿を表示しています。 すべての投稿を表示
ラベル Gradle の投稿を表示しています。 すべての投稿を表示

2014年2月4日火曜日

EclipseでSpockを試す

前提

  • Spock 0.7
  • Groovy 2.0.7
  • 動作確認環境
    • Eclipse 4.3 SR1
    • Eclipse Plugin
      • Groovy Eclipse
      • Gradle IDE
動作確認環境の構築手順については、『Gradleを使ってEclipse 4.3+Groovy Eclipse+Gradle IDEをインストール』を参照

手順

Eclipseで新規プロジェクト(一般プロジェクト)を作成し、プロジェクト直下に、以下のbuild.gradleを配置する。


コマンドラインでプロジェクトのディレクトリに移動し、以下のタスクを実行する。
gradle mkdirs
gradle cleanEclipse
gradle eclipse
プロジェクトを右クリックし、「Refresh」を選択すると、プロジェクトがGroovyプロジェクトとして認識される。再度プロジェクトを右クリックし、「Configure」-「Convert to Gradle Project」を選択すると、Gladleプロジェクトに変換される。

この時点で、以下の設定も確認しておく。

  • 「Windows」-「Preferences」-「Groovy」
    • Use monospace font for JUnit (deprecated)にチェック
    • これにより、JUnit実行時に monospace fontが使用される
  • 「Windows」-「Preferences」-「Gradle」
    • Disable underlininig for .gradle files
    • これにより、.gradleファイルを開いた際に、余計な下線が表示されるのを抑止

以下のSpockのテストケース(SampleSpec.groovy)を、「src/test/groovy」に作成する。


配置したSampleSpec.groovyを右クリックし、 「Run as」-「JUnit Test」を選択するとテストが実行される、テストが失敗する(このテストは意図的に失敗するよう書かれている)。

以下のように修正し、再度テストを実行すると、テストが成功することを確認できる。

2014年1月29日水曜日

Gradleを使ってEclipse 4.3+Groovy Eclipse+Gradle IDEをインストール

Gradleを使って、Eclipse 4.3+Groovy Eclipse+Gradle IDEをインストールするためのbuild.gradleは、以下の通り。


基本的な使い方については、『Gradleを使ってEclipseとEclipse Pluginをインストール』を参照のこと。『Gradleを使ってEclipseとEclipse Pluginをインストール』からの変更点は、以下の通り。

  • installEclipseタスクでインストールするEclipseを Kepler (4.3.1) SR1に変更 (12行目)
  • installPluginsタスクで使用するGroovyEclipseのリポジトリに、Eclipse 4.3のsnapshotを指定(44行目)
    • releaseを指定すると、Window -> Preferences -> Groovy にある、Use Monospace font for JUnitのチェックボックスのオンオフができない
  • uninstallPluginsタスクを追加。(54-63行目)
    • gradle uninstallPluginsで、Groovy EclipseとGradle IDEのアンインストールが可能。
    • リポジトリに、Eclipse本体のUpdate Siteを指定している点に注意。これを指定しないと、依存関係が解決できず、アンインストールが正常に終了しない。

2013年7月9日火曜日

GradleからJSmoothを呼び出して実行可能jarをexe化する

GradleからJSmoothを呼び出して実行可能jarをexe化する手順は、以下の通り。

前提

  • JSmoothがインストールされている


手順

以下のbuild.gradleを用意する。


6行目に、JSmoothのインストールディレクトリを指定する。JSmoothのAntタスクを呼び出すために、jsmoothという名前のconfigurationを定義し(8行目)、そのconfigurationにJSmoothのantタスクのjarを指定(16行目)する。

jarタスク(19行目)で、依存関係のあるjarをlibフォルダにコピー(20-23行目)した上で、実行可能jarを作成している。実行可能jarの作成については、下記サイトの内容をもとにしている。


jsmoothタスク(42行目)で、JSmoothのAntタスクを呼び出し、実行可能jarをexe化している。Antタスク呼び出すjsmoothの設定ファイルは、あらかじめjsmoothを使って保存しておく必要がある。jsmoothの設定については、下記を参照。


なお、この例で使用したjsmoothの設定ファイルは以下の通り。


jsmoothタスクを実行すると、実行可能jarがexe化される。なお、このexeはlibフォルダとともに配布する必要がある点に注意。


関連リンク

2013年7月3日水曜日

Gradleを使ってEclipseとEclipse Pluginをインストール

2014.02.04 追記:Eclipse 4.3対応のスクリプトは、『dev-xconnecting: Gradleを使ってEclipse 4.3+Groovy Eclipse+Gradle IDEをインストール』を参照。

Gradleを使ってEclipse本体とEclipseプラグイン(フィーチャー)をインストールするためのbuild.gradleは、以下の通り。なお、動作確認はWindows上で行っているが、適宜書き換えればUnix系のOSでも動くはず。


2行目で、Eclipseのインストール先ディレクトリを指定している。

Eclipse本体のインストールは、installEcliseタスク(9行目)で行っている。単にEclipseのダウンロードサイトにあるアーカイブをダウンロード(11行目)して解凍しているだけ。必要なら、インストールしたいEclipseのバージョンや対象プラットフォームに合わせて適宜書き換える。eclipse.iniの置き換え(20行目)はお好みで。

Eclipseプラグインのインストールには、上記でダウンロードしたEclipse本体に含まれるp2 director (org.eclipse.equinox.p2.director) を利用する(27行目)。プラグインをインストールする際に、やたら細かいDebugログが出力されるのを抑止するために、logbackの設定ファイルを指定している(33行目)。

インストールするEclipseプラグインは、p2 directorのコマンドオプションとして指定する。p2 directorを使ったEclipseプラグインのインストールについては、下記リンクを参照。


installPluginsタスク(42行目)で、インストールに必要な更新サイトをp2 directorのrepositoryオプション(44, 45行目)に、インストール対象のプラグイン(フィーチャー)をinstallIUsオプション(46, 47行目)に指定している。

repositoryオプションおよびinstallIUsオプションでは、複数の更新サイト、プラグインをカンマ区切りで指定できるが、途中にスペースを入れると実行時エラーとなる点に注意。なお、インストールするプラグインがひとつの場合は、installIUsの代わりにinstallIUオプションを使用する。オプションの詳細については、下記を参照(ただし、installIUsについては記載がない)。


上記のbuild.gradleや関連するファイル(eclipse.iniやlogback.xml)を、任意のディレクトリに以下のように配置する。
build.gradle
logback.xml
│
└─files
     └─eclipse.ini
build.gradleが含まれるディレクトリで以下のコマンドを実行すれば、build.gradleで指定したEclipse本体とEclipseプラグイン(上記の例では、Groovy-EclipseとGradle IDE)がインストールされるはず。
gradle installEclipse installPlugins
なお、mustRunAfter(53行目)は、タスクを直列実行するためにGradle 1.6から追加された機能なので、Gradle 1.5以前で実行する場合は、depandsOnなどに書き換える。

上記ファイルをgradlewとともにgitリポジトリなどに公開しておけば、幸せになれそう。

関連リンク

2013年7月1日月曜日

Gradle Flyway PluginでGradleからGroovy Migration

FlywayのGroovy MigrationをGradleで試す』では、build.gradleからFlywayのクラスを直接呼び出しているが、Gradle Flyway Pluginを使うと、より簡単にGradleからFlywayを実行できる。

前提

手順

FlywayのGroovy MigrationをGradleで試す』のbuild.gradleを、以下のように書き換える。


flywayタスクの設定で、Groovy Migrationに使用するGroovyクラスのパッケージ名(29行目)、およびGroovyクラスのクラスパス(30行目)を指定するのがポイント。

このbuild.gradleにより、flywayMigrateなど、Gradle Flyway Pluginで提供されているタスクが実行できる。使用可能なタスクは、gradle tasksで確認できる。

2013年6月21日金曜日

Gradle Wrapperを試す

GradleプロジェクトをGradle Wrapperとともに公開すると、プロジェクトの利用者の端末にあらかじめGradleがインストールされていなくても、Gradleでのビルドが可能になる(ただし、Javaはインストールされている必要がある)。具体的な手順は、以下の通り。

下記のbiuld.gradleを含むGradleプロジェクトがあるとする。

プロジェクトの公開者は、Graldeがインストールされている端末で、上記のwrapperタスクを実行する。wrapperタスクを実行すると、Gradle Wrapperの実体として以下のファイルが生成される。
gradlew
gradlew.bat
└─gradle
    └─wrapper
            gradle-wrapper.jar
            gradle-wrapper.properties

プロジェクトの公開者は、GradleプロジェクトをGradle Wrapperとともに公開する(例えば、Gitリポジトリとして公開するなら、build.gradleとともに上記のファイルもcommitし、リポジトリに含める)。

プロジェクトの利用者は上記のGradleプロジェクトを取得し(例えば、Gitリポジトリからcloneする)、gradleコマンドの代わりに、Gradleプロジェクト内に含まれているgradlewコマンドを使ってGradleのタスクを実行する。

例えば、gradlew helloを実行すると、Gradle Wrapper作成時に指定したバージョンのGradleが、ユーザのホームディレクトリ直下の.gradle/wrapper/distsフォルダにダウンロードされ(すでにダウンロードされている場合は、それが使用される)、そこに含まれるgradleコマンドを使ってhelloタスクが実行される。

Gradle Wrapperは上記のような仕組みで動作するため、ビルドに使用するGradleのバージョンを固定できるという利点もある。

関連リンク

2013年6月13日木曜日

cucumber-jvm-groovyをGradleで試す

2013.06.13 追記:タイトルを誤って投稿していたため、先日投稿したものと同じ内容のものを再度アップします。

前提

 

手順


まず、以下のfeature (hello.feature) をsrc/test/resourceに配置する。なお、Rubyでは、featureはfeaturesフォルダに配置される。


さらに、以下のbuld.gradleを作成する。


この時点で、gradle cucumberを実行した結果は、以下の通り。
$ gradle cucumber
:compileJava UP-TO-DATE
:compileGroovy UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:assemble UP-TO-DATE
:cucumber
Feature: Hello World

  Scenario: Say hello                        # hello.feature:3
    Given I have a hello app with "Howdy"
    When I ask it to say hi
    Then it should answer with "Howdy World"


You can implement missing steps with the snippets below:

Given(~'^I have a hello app with "([^"]*)"$') { String arg1 ->
    // Express the Regexp above with the code you wish you had
    throw new PendingException()
}

When(~'^I ask it to say hi$') { ->
    // Express the Regexp above with the code you wish you had
    throw new PendingException()
}

Then(~'^it should answer with "([^"]*)"$') { String arg1 ->
    // Express the Regexp above with the code you wish you had
    throw new PendingException()
}


BUILD SUCCESSFUL

Total time: 2.39 secs

上記出力の後半に出力されているテンプレートをもとに、以下のsetp definition (HelloSteps.groovy) を作成し、src/test/groogyに配置する。なお、Rubyでは、step definitionはfeatures/step_definitionsフォルダに配置される。


3,4行目でCucmberから呼び出されるメソッドをmixinしている。これを忘れると、Cucumber実行時に必要なメソッドが見つからず、groovy.lang.MissingMethodExceptionが発生してしまうので注意。

再度gradle cucumberタスクを実行すると、cucumber.runtime.PendingExceptionが発生する。これは、step definitionからthrowされているPendingExpectionそのものであり、まだstep definitionが実装されていないことを表している。

ここから、通常はTDD的な手法でstep definitionとテスト対象の機能を実装していくのだが、今回そのあたりの手順は省略。最終的なstep definitionは以下の通り。


なお、step definition内では、コンテキストが共有される。例えば、上記では、Givenメソッドで定義したhelloインスタンス(5行目)をWhenメソッド内で参照(9行目)している。

テスト対象の機能を実装したHelloクラスは、以下の通り。このファイルは、src/main/groogyに配置する。


再度gradle cucumberタスクを実行する。
$ gradle cucumber
:compileJava UP-TO-DATE
:compileGroovy UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:assemble UP-TO-DATE
:cucumber
Feature: Hello World

  Scenario: Say hello                        # hello.feature:3
    Given I have a hello app with "Howdy"    # HelloSteps.groovy:13
   Given I have a hello app with "Howdy"
   # HelloSteps.groovy:13
    When I ask it to say hi                  # HelloSteps.groovy:17
   When I ask it to say hi                  # HelloSteps.groovy:17
    Then it should answer with "Howdy World" # HelloSteps.groovy:21


BUILD SUCCESSFUL

Total time: 2.734 secs

Cucumberで定義したテストが、無事パスしたことが確認できる。

 

感想


Ruby版のCucumberと同様にcucumber-jvm-groovyが動作することが確認できた。ただ、実際に使用するとなると、featureをどう記述するかは、なかなか難しそう。このあたりは、Use Case Descriptionと同様の難しさがあるように思う。

 

関連リンク

2013年5月28日火曜日

FlywayのGroovy MigrationをGradleで試す

Flywayのホームページの記述(ページ下部の表を参照)ではGroovy Migrationをサポートしていないことになっているが、Java migrationはコンパイル後のJavaクラスを読み込んで動作しているため、原理的にはGroovyでも動作するはず。ということで、FlywayのGroovy MigrationをGradleで試してみる。

前提

 

手順


まずは、src/main/groovy内に、以下のGroovyクラスを作成する。


Java Migrationと同様、FlywayのJdbcMigrationインターフェースを実装したクラスを作成する(9行目)。このクラスの命名規約は以下の通り。

  • パッケージ名
    • 必ずdb.migrationにする
  • クラス名
    •  V(バージョン)__(説明)
    • 先頭は必ず大文字のV
    • バージョンは数字、バージョンの区切り文字はアンダーバー
    • バージョンと説明はアンダーバー2文字で区切る
    • 説明は英数字で単語をアンダーバーで区切る

クラス名の命名規則の詳細は、下記を参照。

上記の移行スクリプトをビルド、実行するためのgradleスクリプトは、以下の通り。


gradleのbuildタスクを実行してGroovy migrationの移行スクリプトをビルドした後、flywayInfoタスクを実行する。
$ gradle flywayInfo
:flywayInfo

+----------------+----------------------------+---------------------+---------+
| Version        | Description                | Installed on        | State   |
+----------------+----------------------------+---------------------+---------+
| 1.0            | Create person table        |                     | Pending |
+----------------+----------------------------+---------------------+---------+

上記出力から、移行スクリプトは存在するが、まだ実行されていない(StateがPending)ことが確認できる。なお、DBが作成されていない場合は、このタイミングで自動的に作成され、上記の表などの情報を含むメタデータを格納するためのテーブル(テーブル名はschema_version)が作成される。

続いて、flywayMigrateタスクを実行し、移行スクリプトを適用する。
$ gradle flywayMigrate
:flywayMigrate
Creating Metadata table: "PUBLIC"."schema_version"
Current version of schema "PUBLIC": << Empty Schema >>
Migrating schema "PUBLIC" to version 1.0
Successfully applied 1 migration to schema "PUBLIC" (execution time 00:00.094s).

再度、flywayInfoタスクを実行する。
$ gradle flywayInfo
:flywayInfo

+----------------+----------------------------+---------------------+---------+
| Version        | Description                | Installed on        | State   |
+----------------+----------------------------+---------------------+---------+
| 1.0            | Create person table        | 2013-05-24 20:20:17 | Success |
+----------------+----------------------------+---------------------+---------+

移行スクリプトが適用されている(StateがSuccess)ことを確認できる。

 

感想


Groovy migrationは、Java migrationと比べて記述の簡略化が期待できる。特に、データの変換やファイルからの読み込みなど、SQL文では記述が難しい、あるいは不可能な処理を移行時に行いたい場合に威力を発揮しそう。

 

関連リンク

 

2013年4月3日水曜日

GroovyからKyoto Cabinetを使用する

いわゆるKVS(キーバリューストア)の実装のひとつであるKyoto CabinetをGroovyから使用する手順は、以下の通り。

前提

  • lib/kyotocabinet.jar(Kyoto CabinetのJavaバインディング)をクラスパスに含める
  • Groovyスクリプト(下記参照)の実行ディレクトリにjkyotocabinet.dll(Kyoto CabinetのDLL)が存在する

手順

下記のGroovyスクリプトを用意する。なお、このスクリプトは、Kyoto CabinetのJavaDocにあるサンプルをGroovyスクリプトにしただけのもの。


Gradleから下記のGroovyスクリプトを実行するには、下記のbuild.gradleを使用する。

execJavaタスクを実行すると、上記のGroovyスクリプトが実行される。


 

感想

別途アプリケーションをインストールすることなくKVSを手軽に利用できるのがよい。ただし、作成されるDBのファイルサイズは小さくない(上記サンプルで6MB程度)。

2013年3月22日金曜日

Gradleでポップアップ通知

Gradleでポップアップウインドウによる通知を行うには、announce pluginを使用する。 Snarl(Windows), Growl(Mac OS X), notify-send(Ubuntu)への通知のほか、Twitterにも対応している。詳細は、下記リンクを参照のこと。

2013年3月11日月曜日

Gradleでソースコードやリソースが含まれるディレクトリを変更する

Gradleでソースコードやリソースが含まれるディレクトリを変更する方法は、以下の通り。


上記の例では、javaソースコードを格納するディレクトリ(デフォルトはsrc/main/java)とリソース(デフォルトはsrc/main/resources)を格納するディレクトリを、ともにsrcに変更している。

なお、上記のlistSrcDirタスクを実行すると、デフォルトのディレクトリは残ったままになっていることが確認できるが、実用上問題ないと思われる。

2013年2月25日月曜日

Gradleでファイルシステムをリポジトリとして利用する

ファイルシステム(Mavenなどで管理されていない通常のフォルダ)をリポジトリとして利用する例は、以下の通り。


この例では、プロジェクト内のlibフォルダ直下をリポジトリに指定している(5行目)。ファイルシステムをリポジトリとして使用する場合、依存関係の指定にはnameとversionを使用する(9行目)。groupの指定は必要ない。上記のように指定した場合はcommons-lang-2.6.jarが、versionを省略した場合はcommons-lang.jarが検索される。

関連リンク

2013年2月22日金曜日

Gradleでファイルシステム上にあるjarへの依存関係を定義する

Gradleを使ってファイルシステム上にある(Mavenなどで管理されていない)jarへの依存関係を定義する方法は、以下の通り。


この例では、プロジェクトのlibフォルダ直下に存在するjarファイルへの依存関係をflatDirを使って指定している(5行目)。jarファイルごとに依存関係を指定する必要がないので、gradleで管理されていない既存のプロジェクトで、依存関係のあるjarがすべてlibフォルダに含まれている場合は、この方法が手っ取り早そう。

関連リンク

2013年2月21日木曜日

GradleでEclipseのクラスパス変数を設定する

GradleでEclipseのクラスパス変数を設定する方法は、以下の通り。


この例では、クラスパス変数GRADLE_USER_HOMEにgradleのユーザホームディレクトリを指定している(5行目)。

eclipseタスクを実行後に、Eclipse上でプロジェクトを更新すると、クラスパス変数がEclipseに反映される。Eclipseで作成したJavaプロジェクトでは、eclipseタスク実行後にJDKへの参照が重複して登録されることがあったので、事前にcleanEclipseタスクを実行しておくのが無難。

Mavenリポジトリなどを使って依存関係を解決している場合、上記のようにクラスパス変数を指定しておくと、Eclipseの.classpathファイルにユーザディレクトリの絶対パスが記述されるのを防ぐことができる。

関連リンク

2013年2月14日木曜日

GradleでGroovyアプリケーションを実行

Gradleでjarに固めていないGroovyアプリケーションを実行する方法は、以下の通り。


GroovyのソースはJavaのクラスにコンパイルされるので、Javaアプリケーションを実行する際と同様、タスクのtypeにはJavaExceを指定する(8行目)。mainには明示的にmainメソッドを持つクラスだけでなく、Groovyスクリプトも指定可能(10行目)。

2013年2月13日水曜日

GradleでJavaアプリケーションを実行

Gradleでjarに固めていないJavaアプリケーションを実行する方法は、以下の通り。


タスクのtypeには、JavaExceを指定する(4行目)。classpathには実行時のクラスパスとしてsourceSets.main.runtimeClasspathを通すしておくのがミソ(5行目)。mainにはmainメソッドをもつクラスの完全修飾クラス名を指定する(6行目)。

2013年2月8日金曜日

GradleでJavaソースのエンコーディングを指定してコンパイル

Gradleで、Javaソースのエンコーディングを指定してコンパイルする方法は、以下の通り。

2013年1月30日水曜日

Gradleで実行したコマンドの標準出力を文字列として取得する

Gradleで実行したコマンドラインのコマンドからの標準出力を、文字列として取得する方法は、以下の通り。


標準出力をByteArrayOutputStreamに割り当て(13行目)、コマンド実行後にそのByteArrayOutputStreamから文字列を取得している(23行目)。

上記のタスクを実行した結果は以下の通り。
$ gradle -q execCommandLine
doFirst
doLast
hello

当たり前だが、コマンド実行時に出力される文字列は、コマンドの実行後でないと取得できない。

2012年12月14日金曜日

Gradle Effective Implementation Guide – Chapter 1

以下、Gradle Effective Implementation Guideの1章についての読書メモ。

いわゆるGetting Started+α。Gradle経験者は見出しと実行例をざっとみて、知らないところや気になるところだけ拾い読みすれば大丈夫そう。Gradle初心者は素直に読み進めればよい。

なお、IDE (Eclipse, IntelliJ IDEA)でのGradleの使用については、12章に記述あり。

2012年12月10日月曜日

GradleでTask Ruleを使ってタスクを定義する

GradleでTask Ruleを使ってタスクを定義する方法は、以下の通り。


 addRuleの第1引数に指定したdescriptionは、tasksタスク実行時にRulesのセクションに表示される。第2引数のクロージャでは、特定の条件にマッチするタスク名に対応するタスクを定義する。この例では、‘sample’で始まるタスク名をもつタスクを定義している。

tasksタスクを実行した結果は、以下の通り。
$ gradle tasks
:tasks

------------------------------------------------------------
All tasks runnable from root project
------------------------------------------------------------

Help tasks
----------
dependencies - Displays all dependencies declared in root project 'aaa'.
dependencyInsight - Displays the insight into a specific dependency in root pr
ect 'aaa'.
help - Displays a help message
projects - Displays the sub-projects of root project 'aaa'.
properties - Displays the properties of root project 'aaa'.
tasks - Displays the tasks runnable from root project 'aaa' (some of the displ
ed tasks may belong to subprojects).

Rules
-----
Pattern: sample<ID>

To see all tasks and more detail, run with --all.

Task Ruleとして定義したタスクを実行した結果は、以下の通り。
$ gradle sample1 sample2
:sample1
1
:sample2
2

関連リンク