Gradle2.4の個人的
にお気に入りな機能
@mike_neck
ってくスタイルです
自己紹介
持田真哉
(@mike_neck)
Java、Groovy好き
おじさん
【質問】
Gradleのプラグイン
作ったことある人?
Gradleのプラグインは利用す
るものであって作るなんて論外
という人?
Gradleは甘え。
真のビルドはmakeのみ。
という人?
そんな皆さんに朗報
Projectに依存せず、プラグイ
ンを作れるようになりました。
Rule based model
configuration
コンセプト
「どのようにビルドする」か
ではなく、「何をビルドする
か」記述する
例を紹介する前にモティ
ベーションの紹介
Haskellのビルドツールcabalの依存性地獄つ
らい
cabalでライブラリーを取ってくると発狂しそ
うなくらい時間がかかる
StackageプロジェクトのLong Term
Support Haskellでテンプレートを共有した
い
問題点:LTS Haskellのリリースが半端なく速
い(週1以上でリリースされる)
最新の環境を整えるためにコマンド叩くの面倒
自動化するためのShellちからがない人生だっ
た(´・ω・`)
–マリー・アントワネット
“Shellが駄目ならGradleでいいじゃない”
GradleでHaskellの
開発環境構築しよう!
せっかくだからRule based
model configuration使おう
概要
実装の規約
モデルをPOJO形式のinterfaceで提供
Default、Model、Mutate、Finalize、
Validateの各ステージごとにルールを記述
プラグインの利用者はモデルをビルドスクリプト
中に指定する
ビルドスクリプト
apply plugin: ‘lts-haskell’
model {
ltsHaskell {
dir = ‘path/to/ltshaskell’
cabal.create {install = ‘happy’}
cabal.create {install = ‘ghc-mod’}
cabal.create {install = ‘yesod’}
}
}
モデルクラス
@Managed //setter/getterを提供
public interface LtsHaskellConf {
String getDir();
void setDir(String dir);
// ManagedSetの中身も@Managedでないと落ちる
ManagedSet<HaskellVersion> getVersions();
ManagedSet<CabalPackage> getCabal();
}
ルールクラス
class LtsHaskell extends RuleSource {
@Model //modelブロックの次のブロックの名前
void ltsHaskell(LtsHaskellConf c) {
c.dir = “${getHome()}/.ltshs”
}
ルールクラス(続き)
@Mutate //モデルへの変更操作・taskを生やしていく
void create(CollectionBuilder<Task> tasks, LtsHaskellConf haskell) {
haskell.versions.each {v ->
ts.create(“create${v}Dir”).doLast {
Files.createDir(Paths.get(c.dir, v))}
ts.create(“sandbox${v}”, Exec) {
workingDir = “${haskell.dir}/$v”; dependsOn “create${it}Dir”
commandLine ‘cabal’, ‘sandbox’, ‘init’
}
haskell.cabal.inject(“sandbox${v}”) {pre, cbl ->
ts.create(“install${cbl}”, Exec) {
実行
$ ./gradlew tasks
LtsHaskell2.8
LtsHaskell2.9
$ ./gradlew LtsHaskell2.9
…
Installed gcc-mod
…
Installed yesod
$
簡単にHaskellの開発環境
作ったどー
╭( ・ㅂ・)‫ﻭو‬ ̑̑ グッ !
後は
https://github.com/mike-neck/LTS-
Haskell-Init をチェック!!!
まとめ等…
モデル(データ)とルール(関数)でタスクを構築
GradleのPluginとかProjectインターフェースの知識なくて
もプラグイン作れる
設定用の口を開くためのメソッドを作らんでもいい
Model-reportタスクで設定できる項目もわかるのでユーザーフ
レンドリー
Gradle3に向けて現在のProjectベースからRuleベースに転換
していくっぽい
以上!

gradle2.4のルールベースモデルコンフィギュレーション