Gradle のビルドファイル (build.gradle) 内で各種ディレクトリへのパスを取得するためのメモ。 プロジェクトのルートディレクトリのような、プロジェクトに関するディレクトリは project オブジェクトのプロパティ、もしくはビルドスクリプト自体のプロパティとして取得できます。 一方、Gradle のインストール・ディレクトリのような Gradle に関するディレクトリは gradle オブジェクトのプロパティとして取得できます。 ちょっと具体的なディレクトリ構造を設定して話を進めた方がいいと思うので、以下のようなディレクトリ構造を想定します： C: gradle gradle-1.12 ・・・ 【gradle.gradleHomeDir】 Users waman ・・・ 【Sydtem.getProperty("user.home")】 .gradle ・・・ 【grad
Gradleは単一プロジェクトだけではなく複数のプロジェクトをまとめて扱うことができて、マルチプロジェクトと呼んでいます。 マルチプロジェクトではいくつかのレイアウトがあるので、以下の3つのプロジェクトを例に書いてみます。 root プロジェクトをまとめるためのプロジェクト share 共通機能をまとめたプロジェクト application アプリケーションがあるプロジェクトでshareプロジェクトに依存しています。 build.gradleの書き方はGradle User Guide/7.3. マルチプロジェクトのJavaビルドなどが詳しいため、ここでは割愛します。 階層構造のレイアウト root配下にshareとapplicationを配置する見た目で分かりやすいレイアウトです。 Gradleのビルドファイルであるbuild.gradleとsettings.gradleはroot直下に
こんにちわ、みけです。 ここ数日、gradleのmaven-publishプラグインにはまっていたので、 そのメモです。 なお、例によって長い記事なので、完成されたbuild.gradleだけ見たい方は、いっちばん下に行って下さい。 ただし、完成されたbuild.gradle読んでも理解できないと思いますけどね。 maven-publishプラグインについて 以下のとおりにメモしていきます。 maven-publishプラグインの基礎 javadoc、sourcesを発行する 複数回、成果物を発行する pomを変更する PGP署名ファイルの発行 課題 maven-publishプラグインの基礎 maven-publishプラグインは任意のファイルを 任意のmavenレポジトリーにアップロードすることができるプラグインです。 次のようなビルドスクリプトでは、以下のようなartifactを発行
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 前回、サーバエラーでインストールできなかった、方法２の「Gradle IDE Pack」プラグインをEclipseにインストールしてみました。 ##方法２：Gradle IDE Packプラグインで、Eclipse上からプロジェクトを作成（再チャレンジ） ###インストール EclipseのHelpメニュー > Eclipse Marketplace..から"gradle"で検索して、Gradle IDE Packをインストールします。 ###Gradle IDE Packのインストール結果 IDE Packとある通り、複数のプラグイン
オンプレミスのシステムを作っていると依存するライブラリはあらかじめインストーラに含めておく必要があるので、簡単に固めたいです。 gradle buildすると.gradleの下に入ったり、Groovyでgrape使ったりすると.groovyの下に入ったりするのですが、それを手動で集めるなんてしたくないし。 依存ライブラリをコピーするGradleタスク build.gradleにコピーするタスクを書きます。 task copyDependencies(type:Copy) { new File('lib').mkdirs() copy { from configurations.runtime into 'lib' } } 実行 $ gradle copyDependencies これでプロジェクトフォルダの下にlibディレクトリが出来てその中にjarがコピーされます。 別解 Gradleの
Copy タスク Copy タスクは Gradle の core で提供されている。 簡単な Copy タスク例は以下。 task copyConfig(type: Copy) { from 'config' into 'build/config' } gradle copyConfig でタスクを実行すると 'config' ディレクトリにあるファイルを'build/config'ディレクトリにコピーする。 exclude コピー対象のフィルタリングは Ant 形式の glob パターンで指定できる。 ファイル名に Test という文字が入ったものを除外するには以下のように指定する。 task copyConfig(type: Copy) { from 'config' into 'build/config' exclude '**/*Test*' } ** とすることで対象ディレクトリ
前回までは Configslurper を使って 環境毎に構成を変更する方法について書きましたが @literalice さんに Gradleでプロパティなどの設定情報を外出しして切り替えて使う で 環境毎に別の Gradle ファイルを取り込んで いろいろと変更する方法を教えてもらったので ちょっと試してみました。 まずは基本から... 別の Gradle ファイルは apply from: 'gradle/other.gradle'で取り込むことができます。 ちなみに 読み込む Gradle ファイルは 相対パス 絶対パス URI の形式で指定できます。 で実際どんなことに使えるかというと 環境毎に 適用するプラグインを変える 環境毎に タスク定義を変える 環境毎に デフォルトタスクを変える OS 毎に 実行するコマンドを変える 共通処理を使い回す などが考えられます。 これらを実現す
@bluepapa32さんの記事に触発されて書いてみました。 次のようなビルドスクリプトがあるとき、 task hello << { println "Hello, $yourname" } Gradleでプロパティ「$yourname」の設定を外だしにして、ビルドごとに結果を柔軟に変えたい、といったことを実現する方法ですね。 @bluepapa32さんも書かれているように、Gradleではさまざまな方法でこれを実現できます。 Gradle で環境ごとに構成を変更するGradle で環境ごとに構成を変更する その２Gradle で環境ごとに構成を変更する その３ここでは、主にGradleの機能を使ってこれを実現する方法について書いてみます。 ビルドスクリプトの設定をいろいろ切り替えるには task hello << { println "Hello, $yourname" } 上記のビルド
マルチプロジェクトは個人的には大変なので余りやりたくないのだが、規模が大きくなると様々な理由で必要になってくる。Gradleにももちろんマルチプロジェクトをサポートする機能がある。今回はそれを紹介。 そもそもマルチプロジェクト化する理由って？ プロジェクトによって色んな理由があると思うが、うちだと以下のような理由がメインかな。 ビルドのルールを標準化したい ビルド時のソースエンコードとかビルドターゲットのバージョンとかバラバラにならないように統一したい。 依存ライブラリのバージョン定義を集約したい 各プロジェクトで使っているOSSライブラリのバージョンがバラバラ...なんてことを避けたい。 ビルドスクリプトを簡略化したい 同じような処理を各プロジェクトで記述するのは無駄だし、メンテナンスも大変。どこかに共通化して定義して、各プロジェクトのビルドスクリプトはすっきりさせたい。 サブプロジェク
追記 (2017-10-21) Java SE 9 のリリースにより、より便利な --release フラグを使えるようになりました！ 下記ページを参考にしてください。 vividcode.hatenablog.com 元の内容 時代は Java 8 ですが、ライブラリなどはまだ Java 7 向けだったり Java 6 向けにビルドすることも多いと思います。 そんなとき、javac の -source オプションや -target オプションを使ってターゲットバージョンを指定しますね。 Gradle を使っていれば次のような感じですね。 sourceCompatibility = 1.7 targetCompatibility = 1.7 ここで、何も気にせず JDK 8 でコンパイルしていると Java SE 7 環境には存在しない Java API のメソッドを使っていることに気付か
ファイルコピーの基本 次のタスクは、ディレクトリ from/dir 以下のファイルを再帰的にコピーします。 from/dir 以下のディレクトリ階層は保たれます。 コピー先のディレクトリ to/dir が存在しない場合は、自動的に作成されます。
最近は Gradle がとってもお気に入りなので プラグインの開発も少しずつ行っているのですが、 折角作成したプラグインやライブラリも Maven リポジトリで公開しないと利用しづらいので どこか公開できる場所がないか探していたところ Github を Maven 公開リポジトリにする という記事を見つけたので ソース管理と合わせて GitHub に Maven リポジトリを作成することにしました。 ただ無料版だと300MB しか利用できないので容量がちょっと心配だったのですが id:kimukou_26 さんのアドバイスによりあまり容量を気にする必要はないことがわかったので GitHub にしました。 それによく考えてみれば そもそも 300MB もコードが書けるほど時間に余裕はないですし... 上記の記事では Maven が使われていましたが、今回は Gradle を利用することもあり
そんな時もあると思う 元々 Eclipse で開発していたプロジェクトを Gradle Project としてインポートすることができないから、Gradle を導入したとしても Eclipse 上で依存性が反映されない。そんな時もあると思う。 そんな時の対処法として、以下の方法を考えた。 build.gradle apply plugin: 'war' def dependenciesCopyTargetDirName = 'dependencies' repositories { mavenCentral() } dependencies { compile 'com.google.guava:guava:18.0' testCompile 'junit:junit:4.11' providedCompile 'javax:javaee-api:7.0' } task deleteDep
gradleのタスクのプロパティ値を定義できる gradle.propertiesで定義した値は、build.gradle内で使うことが出来ます。 なので、署名時に必要な情報をgradle.propertiesで定義してファイル自体はリポジトリに含めない方法を取っていました。 しかし、さまざまなプラグインで各プロジェクトのgradle.propertiesで定義した値を使うことがあるため、リポジトリに含めないとTravis CIやサーバに用意したJenkinsなど、CIサーバでビルドするときにエラーが起きることが多々あります。 リポジトリに含めたくない情報は~/.gradle/gradle.propertiesで定義する ~/.gradle/gradle.propertiesで定義した値も、プロジェクトから参照できます。 各プロジェクトで定義した値と名前が重複していた場合は、~/.grad
これは、 G* Advent Calendarの15日目の記事です。 昨日は @int128 さんの Gradle Slashプラグインをリリースしました #gadvent でした。 明日は @tyama さんです。 はじめに Gradle 便利ですよね。便利すぎて Ant や Maven には戻れないです。 なにが良いって、設定ファイルである build.gradle の記述量が、 Ant の build.xml や Maven の pom.xml と比べると非常に少なくて済むのが良いです。 build.gradle は、設定ファイルと言いつつも、その実体は Groovy で書かれたスクリプトファイルです。 Gradle は、 Groovy の持つメタプログラミング機能や省略記法などを利用して、設定を簡潔に記述できるようになっています。 これはメリットなのですが、一方で Groovy の
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
