2011年12月16日金曜日

ConfluenceのHTML→PDF変換ライブラリを利用する

JIRA Advent Calendar 2011、15日目です。

ってすみません、ConfluenceネタですがまあJIRA使ってる人は連携して使ったりしますよねとか、そんな感じで。
GradleのユーザーガイドPDFに変換するときにお世話になったので、紹介してみます。

Confluenceは、バンドルされているプラグインでページをPDFに変換して出力できるのですが、この機能に使われているライブラリを使って、XHTMLをPDFに変換しようという話です。

ConfluenceのXHTML→PDF処理にはFlying SaucerというJavaのライブラリが使われています。
Flying Saucerを使うと、XMLやXHTMLファイルを、PDFやSWT、Swingのスクリーンに出力させることができます。デザインはCSSで指定できます。

ただ、このFlying Saucer、PDFに変換したときに、文字列が空白位置でしか改行されません。
英文Onlyならいいのですが、日本語で長文をだらだら書いていると画面外にあふれて見えなくなってしまうわけですね。
ConflueceのPDFエクスポートでの禁則 - azuki note

この問題を、Atlassianさんがパッチを当てて修正しているので、しかもMavenリポジトリ上に上げてくれているので、今回はそれを使います。

@Grape+Groovyスクリプトでもいいですが、いろいろ面倒なのでGradleスクリプトで。

フルのサンプルはGithubに上げたのでそちらを見てもらうとして、ポイントだけ書いておきます。

変換元のHTMLとCSSのサンプル

AtlassianさんのMavenリポジトリからFlying Saucerを取得

AtlassianさんのMavenリポジトリから、パッチの当たったFlying Saucerライブラリを取得します。
GradleとかMavenとかIvyとか、そのあたりの設定に依存関係を追加するのがいいですね。

ライセンスが気になるところですが、LGPLのままみたいなので大丈夫でしょう、多分…

Mavenリポジトリ
https://maven.atlassian.com/repository/public
アーティファクト
org.xhtmlrenderer:xhtmlrenderer:8.3-atlassian

Flying SaucerはPDF生成にiTextを使うのでそちらも

Mavenリポジトリ
セントラルリポジトリ
アーティファクト
com.lowagie:itext:2.0.8
// Gradleの例
buildscript {
    repositories {
        mavenCentral()
        mavenRepo url: "https://maven.atlassian.com/repository/public"
    }
    dependencies {
        classpath "org.xhtmlrenderer:xhtmlrenderer:8.3-atlassian"
        classpath "com.lowagie:itext:2.0.8"
    }
}

PDFへの変換処理

PDFへの変換処理は、次のような感じで書きます。

import org.xhtmlrenderer.pdf.ITextRenderer

def renderer = new ITextRenderer()
renderer.setDocument(new File("sample.html"))
renderer.layout()
new File("sample.pdf").withOutputStream {
    renderer.createPDF(it)
}

このコードを実行すれば、sample.htmlがsample.pdfに変換されます。

CSSでPDFに埋め込むフォントを指定する

日本語を使うには日本語フォントをPDFに埋め込むか参照させる必要があります。変換元のHTMLに次のようなCSSを適用しましょう。

@font-face{
    font-family: "IPAexGothic";
    src: url(ipaexg.ttf);
    -fs-pdf-font-embed: embed;
    -fs-pdf-font-encoding: Identity-H;
}

body {
    font-family: "IPAexGothic";
}

なんか、使えるフォントと使えないフォントがあるみたいです。

fsなんたらはFlying Saucerのベンダー拡張ですね。詳しくはFlying Saucerのユーザーガイドを見てみてください。

長い文章を折り返すための設定

Atlassianさんのパッチが当たったFlying Saucerを使うと、次のようにCSSでword-wrapを指定することで長い文章が折り返されるようになります。

p {
    word-wrap: break-word;  
}

おわりに

いやぁ、便利ですね。ちょっとしたPDF作るだけなら、それ用のHTMLファイル作って変換するのが簡単かもしれません。

さて、かなり脱線気味でしたが、こんなところで。
引き続きJIRA Advent Calendar 2011をお楽しみください。

2011年12月6日火曜日

GrailsのプラグインリポジトリとしてGithubを使う

G* Advent Calendar、6日目いってみます。
今日を境に、公開Grailsプラグインの数が爆発的に増える……といいなーという感じで

Grails version
2.0.0.RC1

Grailsプラグインのリポジトリには、Maven形式のリポジトリが使用できます。

つまり、MavenのリモートリポジトリをGithub上に構築する以下の手法を使えば、GraisプラグインのリポジトリをGithub上に持てるわけですね。
Github を Maven 公開リポジトリにする
GitHub を Maven 公開リポジトリにする (Gradle 編)

何ができるの?

例えば、私はGrailsのAWSプラグインにパッチを当てたものをGithub上に公開しています。1

このプラグインは、次のようにしてどこからでも使用できます。

// grails-app/conf/BuildConfig.groovy
// ...
grails.project.dependency.resolution = {
    // ...
    repositories {
        grailsPlugins()
        grailsHome()
        grailsCentral()

        // ...
        // Github上のマイプラグインリポジトリを指定
        mavenRepo "http://literalice.github.com/maven-repo/releases"
    }
}

# 上で指定したプラグインリポジトリからプラグインをインストール
cd grails-project
grails install-plugin aws 1.2.12.1.p1

とまあ、このように、改造したり開発したりした非公式オリジナルプラグインを簡単に公開して使えるようにしちゃおうというのが目的です。

GrailsのプラグインはzipファイルのURLを指定してインストールできるので他にいくらでも方法はあるわけですが、不特定多数に公開して良いなら今のところこれが一番手軽なんじゃないかなぁと。

この記事は、私がAWSプラグインを改造して公開したときの手順を思い出しながら書いていますが、オリジナルのプラグインを公開するときも同じような感じです。

以下がその手順です。

プラグインのソースコードを入手する

  • Github上にあるプラグインのソースコードをフォークして、手元にクローン
  • grails create-plugin コマンドでプラグインプロジェクトを作成する
  • などなど

プラグインのバージョン番号を更新する

既存のプラグインを改造する場合は、バージョン番号がオリジナルのものと被らないように変更しておいた方が良いでしょう。1.0.0.p1、といった風に適当なサフィックスを付けておきます。

    // XXGrailsPlugin.groovy - プラグインディスクリプタ
    // ..
    def version  = "1.0.0.p1"
    // ..

GrailsのReleaseプラグインをインストールする

プラグインのビルド、リポジトリへの公開は、このReleaseプラグインを使います。

Grails2系のcreate-pluginでプラグインプロジェクトを作成した場合は既にプロジェクトにインストールされているかと思いますが、そうでなければ自分でインストールする必要があります。

install-pluginコマンドでインストールせず、必ずBuildConfig.groovy上でプラグインを追加してexport設定を追加します。そうでないと、このマイプラグインをインストールしたときに、インストール先のプロジェクトもreleaseプラグインに推移的に依存するようになってしまいますので。

ちなみにAWSプラグインはinstall-pluginでreleaseプラグインをインストールしていたようなので、改造版ではこちらも修正しています。

// grails-app/conf/BuildConfig.groovy
// ...
grails.project.dependency.resolution = {
    // ...
    plugins {
        // ...
        build(':release:1.0.0.RC3') {
            export = false // このプラグインはインストール先のプロジェクトには不要
        }
    }
}

プラグインをがしかし実装

プラグインをオレオレに改造します。がしかし好きな機能を実装します。

Github上にMavenリポジトリを構築する

好きな機能は実装できましたか? ではプラグインを公開しましょう。

Github を Maven 公開リポジトリにする
を参考に、MavenリポジトリをGithub上に構築します。

おおざっぱに言えば、

  1. ローカルにフォルダを作ります(「D:\mvn」など)。
  2. そのフォルダをgitのリポジトリとして初期化します。
  3. そのリポジトリに「gh-pages」という名前のブランチを作ります。
  4. 作った「gh-pages」ブランチをgithubにプッシュします
  5. おわり

後は、このフォルダにMavenリポジトリ構造でファイルを追加してプッシュすれば、Github上にそのファイルを公開できるわけですね

ここでは、「D:\mvn」にgitのリポジトリを作ったものとします。

ローカルフォルダにGrailsプラグインをリリースする

先ほどgitリポジトリとして初期化したフォルダ「D:\mvn」にプラグインをリリースします。

Grailsのreleaseプラグインは、SubversionリポジトリやリモートのWebDAV Mavenリポジトリにプラグインをリリースできますが、ローカルにはき出すことも可能なようです。

リリース先の指定方法はreleaseプラグインのマニュアルに載っています。

プロジェクトのBuildConfig.groovyか、ユーザーのホームディレクトリにsettings.groovyというファイルを置いて設定することができます。

バージョン管理に入れるであろうBuildConfig.groovyに、ローカルのファイルパスを書き込むというのはダサい気がするので、私はsettings.groovyを使いました。以下のように設定します。

// ~/.grails/settings.groovy
grails.release.scm.enabled = false // プラグインのソースコードはリリースしない

grails.project.repos.default = "localRelease" // リリース先未指定時のリリース先
grails.project.repos.localRelease.url = "file:///D:/mvn" // リリース先"localRelease"のURL

設定が終わったら、プラグインのプロジェクトディレクトリに移動して、リリースコマンドを実行します。2

cd my-grails-plugin
grails publish-plugin

コマンドが正常に終了すれば、「D:\mvn」にプラグインのzipファイル、pomファイルなどが生成されているはずです。3

MavenリポジトリをGithubにプッシュ

「D:\mvn」に生成された全てのファイルをコミットし、github上にプッシュします。

これで、作成したプラグインをどこからでも使用できるようになりました。

公開したプラグインを使う

公開したプラグインは、前述のように「BuildConfig.groovy」にGithub上のプラグインリポジトリを追加すれば使用できます。

リポジトリのURLは、Githubユーザー名が「literalice」、プッシュしたMavenリポジトリのフォルダ名が「mvn」であれば、「http://literalice.github.com/mvn」となります。

// grails-app/conf/BuildConfig.groovy
// ...
grails.project.dependency.resolution = {
    // ...
    repositories {
        // ...
        // Github上のマイプラグインリポジトリを指定
        mavenRepo "http://literalice.github.com/mvn"
    }
}

# 上で指定したプラグインリポジトリからプラグインをインストール
cd grails-project
grails install-plugin myplugin 1.0.0.p1

Twitterとかで通知

使って欲しい人に向けて、プラグインのリリース情報を通知します。プラグインリポジトリのURLとプラグイン名、プラグインバージョンを教えてあげれば大丈夫なはず。

まとめ

これでもう、プラグインのバグ修正も機能追加も待つ必要ないですね。直して公開です。

わざわざGrailsの公式リポジトリにプラグインを公開する必要もないですね。プラグイン名とリポジトリのURLを一緒に教えてあげれば大丈夫です。

気が向きましたら、本家にpull requestとか、プラグインを公式リポジトリに公開とかするとよりナイスですね。

Githubの最大容量は300MBらしいですが、普通のプラグインはそんなに容量大きくならないので大丈夫じゃないでしょうか、多分。

G* Advent Calendar、7日目は@masanobuimaiさんです。



注1: AWSプラグインは、GrailsからAmazon Web Serviceを簡単に使えるようにするものですが、SESでメールを送信するときに文字セットを指定できなかったためパッチを当てて使っています。

注2: 本来であれば、

cd my-grails-plugin
grails publish-plugin --repository=localRelease
とすることで、リリース先を明示的に指定できるはずなのですが、私の環境ですと上手く動かなかったので、デフォルトのリリース先をsettings.groovyで設定して、リリース先を指定せずにリリースできるようにしています。

注3: 「WARNING: unknown protocol 'file' for repository」というワーニングが出るのが気になりますが…とりあえず、問題なくリリースできるようです。

2011年11月28日月曜日

Load the JQuery Library via CDN with Grails Resources Plugin

Grails version
2.0.0.RC1
Resources Plugin version
1.1.1

You can use the jquery library on existing CDN networks with Grails Resources Plugin in this way.

// grails-app/conf/XXResources.groovy
modules = {
    // Defines JQuery's CDN network
    overrides {
        def jqueryVersion = org.codehaus.groovy.grails.plugins.jquery.JQueryConfig.SHIPPED_VERSION
        'jquery' {
            resource id:'js',
                     linkOverride:"http://ajax.googleapis.com/ajax/libs/jquery/${jqueryVersion}/jquery.min.js"
        }
    }
}

Note: The resources plugin load a resource via 'linkOverride' url only when it is not in debugging mode.
see also: Grails Resources Plugin: Debbugging

2011年11月25日金曜日

Cloud Foundry上のMongoDBに既存データを流し込む

Cloud Foundryは、VMWare社が開発しているPaaS環境です。現在、クラウド上でβ試験中の環境が無料で試用できます。

GrailsなどのWebフレームワーク、MongoDB、MySQL、Redis等々、様々なサービスを起動して使用できるようです。

基本的な使い方はこちらを見ていただくとして、
http://d.hatena.ne.jp/y-kawaz/20110425/1303708958
http://support.cloudfoundry.com/entries/20054091-vmware-cloud-foundry-getting-started-japanese

Cloud Foundryでは「vmc」というCLIが提供されていて、これでアプリのデプロイやらを行うわけですが、
これに最近追加された「tunnel」というサブコマンドで、このPaaS上のMongoDBに既存データを流し込めるらしいので試してみました。

今回は、mongodumpで既存データをバックアップし、mongorestoreでCloudFoundry上のMongoDBにデータを流し込みます。
これらのツールの使い方は、こちらの記事がわかりやすいです。
http://d.hatena.ne.jp/rougeref/20110325

流し込むデータファイルは、前もってmongodumpでダンプしておいたものとします。

vmc tunnelって?

vmc tunnelを使うと、あたかもローカルのポート10000番で動作しているMongoDBに接続しているかのように、CloudFoundry上のMongoDBに接続できます。
ローカル環境から、


mongo localhost:10000 --username xxx --password xxx

という感じでCloudFoundry上のmonogodに接続して操作できるようになるわけですね。

詳しくは、以下でわかりやすく図解してくださっています。
http://blog.udcp.net/2011/11/22/vmc-tunnel/

今回の作業も、すべて上記の記事を見ながら行いました。

vmcのインストール

Cloud Foundry上のアプリケーションやMongoDBなどのサービスの操作は、vmcというRubyGemのツールで行います。

こちらを参考に、次のように必要なgemを入れます。


gem install vmc --pre
gem install caldecott

ちなみに、64ビット版のWindows7上だとネイティブライブラリのコンパイル時にエラーになってインストールできませんでした。

エラーメッセージ見る限り、64ビット版のWindowsには対応していないように感じましたが、特に深く追求する気もないのでVMWare上のCentOSで実行することにします。

ネイティブライブラリ依存は将来的に取り除かれる予定らしいので、それに期待しておきましょう。
http://blog.cloudfoundry.com/post/12928974099/now-you-can-tunnel-into-any-cloud-foundry-data-service

Rubyが入っていないときは、最近はRVMでインストールするのがナウいらしいので、この辺を参考にしていれましょう。
https://rvm.beginrescueend.com/
http://d.hatena.ne.jp/mirakui/20100502/1272849327

MongoDBのインストール

前述の通り、CloudFoundry上のmongodには、ローカルから

mongo localhost:10000 --username xxx --password xxx
って感じで接続します。つまり、ローカル上にmongoクライアントをインストールする必要があるはず。

mongoのインストール方法はこちら。公式がyumリポジトリを提供してくれており、インストールは異様に簡単です。
http://www.mongodb.org/display/DOCS/CentOS+and+Fedora+Packages

現在CloudFoundry上で稼働しているMongoDBはバージョン1.8.1なので、合わせた方が良いかもしれません。
私は既に2.0.1を入れてしまっていたのでソレを使いました。今回の作業では特に問題は起きてません。

vmc tunnelの実行

http://blog.udcp.net/2011/11/22/vmc-tunnel/に書かれているとおりにvmc tunnelを実行します。

% vmc tunnel
1: mongodb-ea00999
2: redis-8dcyyyy
Which service to tunnel to?: 1
Password: ***********
Getting tunnel connection info: OK

Service connection info:
  username : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  password : yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
  name     : db

Starting tunnel to mongodb-ea00999 on port 10000.
1: none
2: mongo
Which client would you like to start?: 1
Open another shell to run command-line clients or
use a UI tool to connect using the displayed information.
Press Ctrl-C to exit...

最後に「2」を選べば、さっきインストールしたローカルのmongoシェルが勝手に起動して、CloudFoundry上のmongodにつなぎに行ってくれます

今回はmongoのインタラクティブシェルには用はないので、「1」を選んで待機させておきます。

これで、ローカルのポート10000番を通して、CloudFoundry上のMongoDBに接続できるようになりました。

mongorestoreの実行

ターミナルをもう一つ立ち上げて、mongorestoreを実行します。

接続情報は、vmc tunnel実行時に表示されるので、待機中のターミナルをみれば載っているでしょう。

Service connection info:
  username : xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  password : yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
  name     : db

CloudFoundry上のMongoDBへの接続情報を確認したら、mongorestoreを実行してデータを流し込みます。

流し込むデータファイルは、前もってmongodumpでダンプしておきます。

mongorestore -h localhost:10000 -d db(上で確認した「name」) -c book(ダンプしたコレクション名) \
  -u (上で確認したユーザー名) -p (上で確認したパスワード) --drop \
  dump/db/book.bson(mongodumpで取得したダンプファイル)

これで、MongoDB上へデータが流し込まれているはず。

mongoシェルなどでデータを確認したら、待機させておいたvmc tunnelを終了させて完了です。

既存のデータでCloud Foundryを試してみたい、運用してみたい、といった場合もこれで何とかなりそうですね。

2011年7月14日木曜日

JQueryUI Theme in Grails Resources Plugin

Grails version : 1.3.7
Resources Plugin version : 1.0

Resources PluginとJQuery UI Pluginと使っているときに、JQuery UIのカスタムThemeを指定する方法が分からなかったのですが、
以下のようにすることで今のところ正常に動いています。

conf/XXResources.groovy (Resources configuration file)
modules = {
  overrides {
    'jquery-theme' {
      // location of a jquery theme css
      resource id:'theme', url:'/jquery-ui/themes/cupertino/jquery-ui-1.8.11.custom.css'
    }
  }
}

2011年4月6日水曜日

GrailsのMailプラグインでエンコード指定(ISO-2022-JP)なメールを送る

Grailsのバージョンは1.3.7
Mailプラグインのバージョンは1.0-SNAPSHOT

結構やってるんだけど、やり方忘れるので備忘録ということで

import org.springframework.mail.javamail.MimeMailMessage
import org.springframework.mail.javamail.MimeMessageHelper

def mailService

/**
* メールを送信する
*
* @param mailParams メールサービスへ渡すパラメータ
*/
def sendMail(Map mailParams) {
mailService.sendMail {
helper = new MimeMessageHelper(
mailSender.createMimeMessage(), multipart, "ISO-2022-JP")
message = new MimeMailMessage(helper)

to mailParams.to
from mailParams.from
subject mailParams.subject
body mailParams.body
}
}

上のコードをサービスクラスとかに入れて呼び出します。
Mailプラグインの設定方法はここに書いてあるままです。

Grails Mail Plugin

最近はUTF-8でもいいんでしたっけ?
でもまあ日本語メールならISO-2022-JPにしといて損はないんじゃないでしょうか。

2011年3月15日火曜日

Gradleでプロパティなどの設定情報を外出しして切り替えて使う

@bluepapa32さんの記事に触発されて書いてみました。

次のようなビルドスクリプトがあるとき、
task hello << {
println "Hello, $yourname"
}
Gradleでプロパティ「$yourname」の設定を外だしにして、ビルドごとに結果を柔軟に変えたい、といったことを実現する方法ですね。

@bluepapa32さんも書かれているように、Gradleではさまざまな方法でこれを実現できます。
ここでは、主にGradleの機能を使ってこれを実現する方法について書いてみます。

ビルドスクリプトの設定をいろいろ切り替えるには


task hello << {
println "Hello, $yourname"
}
上記のビルドスクリプトをそのまま「gradle hello」と実行しても、yournameなんてプロパティはないですと怒られて失敗するので、プロパティyournameをビルドスクリプトに設定してやる必要があります。

このとき、プロパティyournameのような設定情報をビルドスクリプトの外で設定し、切り替えられるようにするには、

  • コマンドライン引数で直接設定
  • 環境変数→プロパティ自動変換機能を使う
  • gradle.propertiesをユーザーのホームディレクトリまたはプロジェクトディレクトリに置く
  • 外部ファイルをビルドスクリプトなどの先頭で読み込む
  • 初期化スクリプト(init.gradle)を使う
の方法が考えられます。

詳しくはユーザーガイド(Gradleプロパティとシステムプロパティ)など見てもらうとして、ここでは一つずつ使いどころなど簡単に考えてみたいと思います。

コマンドライン引数で直接設定


コマンドラインオプションを使って、yournameのようなプロパティを設定できます。
gradle -Pyourname=literalice hello

:hello
Hello, literalice

BUILD SUCCESSFUL
設定したいプロパティが少ないときや簡単なデモなどで使えますね。

環境変数→プロパティ自動変換機能を使う


Gradleは、プレフィックス「ORG_GRADLE_PROJECT_」の付いた環境変数を定義しておくと、その値をプロパティに変換してくれる機能があります。
set ORG_GRADLE_PROJECT_yourname=literalice

gradle hello

:hello
Hello, literalice

BUILD SUCCESSFUL
設定するプロパティの数がそう多くない場合で、ビルドするマシンごとにプロパティを切り替えたいとき、jenkinsなどのCIサーバー上で簡単にビルドを設定したいときなどに。

Gradleだと、環境変数を直接ビルドスクリプトで読む(System.getenv) ようなシチュエーションは限られますね。(外部ツールとの連携時とか?)

gradle.propertiesをユーザーのホームディレクトリまたはプロジェクトディレクトリに置く


gradle.propertiesという名前でプロパティファイルを作成し、プロジェクトディレクトリまたはユーザーのホームディレクトリに置いておくと、読み込んで使ってくれます。

なお、プロジェクトディレクトリ→ユーザーのホームディレクトリの順に読み込まれます。

ユーザーのホームディレクトリのプロパティが優先して使われる(上書きする)ということです。

~/.gradle/gradle.properties
yourname=literalice
実行結果
gradle hello

:hello
Hello, literalice

BUILD SUCCESSFUL

ホームディレクトリのgradle.propertiesは、すべてのビルドスクリプトで使われます。

ツールの場所(grailsHomeとか、javaHomeとか)、ユーザーの(sshやwebページなどへの)ログイン情報などを設定するのに良いかもしれません。

ちなみに、ここまでの設定方法だと、どれ選んだ場合でもビルドスクリプトの方は変更する必要ないんですよね。素晴らしい。

外部ファイルをビルドスクリプトなどの先頭で読み込む


いくつか方法はありますが、

  • Groovyの機能で外部ファイルを読み込んで展開する
  • 外部のスクリプトファイルを読み込む

の二つを紹介しようと思います。

1. Groovyの機能で外部ファイルを読み込んで展開する

この方法は、@bluepapa32さんが解説されています。

GroovyのConfigSlurperを使って、Groovyスクリプト形式の設定ファイルを読み込み、プロパティに展開しています。

既存の設定ファイル(GrailsのDataSource.groovyやBuildConfig.groovyなど)を読み込むときに便利です。

2. 外部のスクリプトファイルを読み込む

たとえば、プロパティのセットをLinux向け、Windows向けなどいくつか定義しておいて、それらを簡単に切り替えできるようにしたい、というときはこの方法が使えます。

build.gradle
apply from:"default.config.gradle"
apply from:"${env}.config.gradle"

task hello << {
println "Hello, $yourname"
}

設定ファイルをいくつか用意します。
default.config.gradle
yourname = "the name in the default config"
linux.config.gradle
yourname = "the name in the linux config"
windows.config.gradle
yourname = "the name in the windows config"

実行するときは、こんな感じ

gradle -Penv=windows hello

:hello
Hello, the name in the windows config

BUILD SUCCESSFUL

イメージとしては、apply from:"..."で読み込んだファイルが、そのままペーストされる感じで動きます。

読み込んでいる外部スクリプトは、ただのGradleビルドスクリプトなので、上記のようなプロパティの設定だけでなく、タスクの定義やプロジェクト設定の変更など、Gradleでできることはなんでもできます

初期化スクリプト(init.gradle)を使う


Gradleには初期化スクリプトという仕組みがあって、マシン固有の設定をここでも行うことができます。

具体的には、「init.gradle」というファイルをユーザーのホームディレクトリに置いたり、コマンドラインオプションで渡してやったりすると、ビルドが構築される前に「init.gradle」が実行されるというものです。

初期化スクリプト

このスクリプトで、今までのように単純なプロジェクトプロパティをセットするにはかなりめんどくさい方法をとる必要があり現実的ではないです。

ビルドのライフサイクルに対するリスナーや、カスタムのロガーを登録する、外部ツールとの連携に便利らしいのですが、私の使用した範囲だとまだ使いこなせたことはないですね…

まとめ


Gradleのビルドを設定する方法をいくつか見てきましたが、こんな風にいろいろな方法を選ぶことができるのはGradleの魅力の一つだと思います。

場面場面に応じて、適切な方法を選んでいきたいですね。