AndroidのCIでbuild-toolsの新しいバージョンが見つからない場合の対処

久しぶりにAndroid-ObservableScrollViewのAndroid SDKのバージョンなどを
アップデートしたが、Travis CIでもwerckerでもビルドが失敗してしまった。

もちろんローカルでは成功している。

API Levelの問題などではなく、build-tools-23.0.2が見つからなかったというもの。

結論としては、toolsを先にアップデートすれば良い。

AndroidのテストタスクだけGradleでログ出力する

久々のAndroid関連ネタ。
Android-ObservableScrollViewでは、なるべくカバレッジ100%になるようテストを書こうとしている。
しかしテストが増えてきたせいか、Travis CIでのテスト実行中に出力がない時間が10分以上続いてしまい、ビルドが失敗することが多くなってきた。
テスト系のタスクだけもう少しログ出力させられないか？
を解決する方法について紹介する。

まず、テスト系限定でなく、すべてのタスクに対して
INFOレベルでログ出力するのなら
Gradle的には以下のように–infoなどをつければいい。

./gradlew connectedCheck --info

しかしすべてのタスクがINFOレベルで出力されるのは
見づらくなるだけなので避けたい。

Gradleで表記ゆれをチェックするプラグインgradle-spelling-plugin

GradleからCoffeeScript、LESS、Bowerを使うプラグインgradle-web-resource-plugin
に続き、Javaプロジェクトの開発で使えるGradleプラグイン gradle-spelling-plugin を作ったので紹介。

これで何ができるかというと、ブラックリストに単語、表現を登録して、それを探していくだけ。
見つけた場合は、代わりにこれを使ってね、と警告する。
見つけた場合にビルドエラーとするかどうかは設定できる。
それだけ、ではあるのだけれど、ちょうどいいものが見つからなかったので作った。

Gradleを使い出すと、Gradleですべてチェックできるようにしたいと考えるようになる(たぶん)。
そして自動化したいと考える。
だから、grepしたりIDEで検索すればいいものだったとしても
Gradleで使える形になっていることが大事。

ライブラリが採用されてた！その2

YouTubeの最近の新しい動画について、今朝通知メールがきて、ふとAndroid Developersチャンネルの動画が目に留まった。
フリルのFablicさんの事例紹介だった。

マテリアルデザインを採用したらこんなに○○になった！というものだったが、マテリアルデザインのライブラリを作った自分としてはどんなものかチェックしなくては、と動画を観てみると…
おや、この動きはもしかして…！
ダウンロードしてみると、なんと使われてました！
Android-ObservableScrollViewが！
ライセンス欄にちゃんと書いてくれている。

こんな人気アプリに採用されているのは、やっぱり嬉しいですね。
Fablicさんありがとうございます。
ライブラリを使ってくれる方は
ぜひデベロッパーにフィードバックした方がいいと思います(もちろん、応援のフィードバックを…)。
特に個人で開発してると思われるプロジェクトに対しては。
メンテナンスしようというモチベーションが変わります。
(と言いつつ、諸事情で別のプロジェクトを優先していてなかなか最近できてないけど、気持ちはあります)

皆、どういう風にライブラリを採用しているのかは分からないけど、もしかすると受託開発だからオープンにできない、表立って使ってるよと言えない立場にあるのかもしれない。
それでも、もし何もフィードバックしていなければ、せめてGitHubのプロジェクトにスターを付けてくれるといいと思う。
良いと思ったから採用してくれているはずなのに、
こういう形でしか「使ってるよ！」というのが伝わらないのは残念だなと思う。

…と考えてみて、
自分も全てはそうしていなかったかもしれないなと反省。
作ったライブラリが依存しているライブラリなど、
見直してみようかなと思う。

Spring Boot 1.3.0.RC1を試してみて

現在Spring Bootを使ったWebアプリを開発しているのだが、Spring Boot 1.3.0のリリースを心待ちにしていて、実際にMilestone/RC版を取り込んでみている。

その中でいくつかハマったこと(ドキュメントをよく読めという話だが)や、これは使ってみたいと思った機能などを書き留めておく。
これは1.3.0のリリース前のM5とRC1のことなので、そこはご注意を。

Gradleスクリプトの構造化

全然知らなかったのだけど、Gradleのプロジェクトでは、buildSrcというディレクトリを作ればビルド専用のクラスなどを定義できる。

例えば buildSrc/src/main/groovy/Foo.groovy というファイルを作りclass Fooとか定義すれば、build.gradleから普通に new Foo()というふうに参照できる。
classpathとか書く必要はない。

build.gradleは使っていくうちに段々と肥大化してきてしまうが、
これを使えば、複雑なtaskなどはきれいに構造化できるかもしれない。

これまで使っていたやり方としては、apply from:を使う方法。
以前本家GradleのGitHub上のプロジェクトを参照したのだが(ここでbuildSrcに気づいても良かったんだが・・・)、gradleディレクトリにいくつもgradleファイルを置いている。

そして、これを apply from: "${rootDir}/gradle/hoge.gradle"のように読み込む。

まとまった機能があればこのように切り出せばマルチプロジェクトでもそれなりにまとめられる。

しかしファイルを切り出してもそれはあくまでフラットな構造のスクリプトであり、ぐちゃぐちゃになりやすい。
クラス化したいなぁと思うことが何度もあったが、そんなときにbuildSrcを活用すると良いのかもしれない。

GradleからCoffeeScript、LESS、Bowerを使うプラグインgradle-web-resource-plugin

前のエントリで少し触れてしまったけど、少し前に作り、最近大幅に改造してひとまず仕上げたGradleプラグインgradle-web-resource-pluginの紹介です。
というか、開発の経緯の説明という感じですが・・

このプラグインで何ができるのかというと、GradleのタスクでCoffeeScriptやLESSのソースをコンパイルでき、Bowerで利用できるライブラリを組み込むことができる。
しかもNode.js、npmなどのインストールは不要。