mike-neckのブログ

Java or Groovy or Swift or Golang

Gradle2.11リリースノート意訳(また途中)

gradle

gradleのバージョン2.11がとっくの昔に出ていたので、リリースノートを意訳しておきました。

原文はこちら

Gradle2.11ではソフトウェアモデルとIDE連携およびコンティニュアスビルドを強化しています。

ソフトウェアモデル改善はGradleの現在の目標となっています。ネイティブ対応とPlayフレームワーク対応から始まったソフトウェアモデルはJavaのフルサポートを目標として開発しています。今回は新しいJavaプラグインでのJUnitによるテストのサポートとコンパイルに関するジョブの最適化を行っています。こうした改善に伴い新しいソフトウェアモデルによるプラグイン開発も改善されています。

ソフトウェアモデルだけでなく、既存のJavaプロジェクトもGradle2.11の恩恵を受けられます。IDE連携が改善されたことにより、IntelliJ IDEAやEclipseなどのIDEでGradleプロジェクトを扱いやすくなっています。IDEのプロジェクトファイルとツーリングAPIの改善によりこれがもたらされています。

ビルド中の変更監視によりコンティニュアスビルドはより信頼できるものとなっています。これはユーザーにこれこそがGradleで開発することであると実感できる本当におすすめの機能です。

今回もGradleコミュニティのおかげでGradle2.11をリリース出来ました。主に次の箇所でコントリビュートを受けています。

新機能など

ソフトウェアモデルでのプラグイン開発サポート

プラグインがマネージド型をカスタムソースセットとして扱えるようになった

LanguageSourceSet型は@Managedを継承した型として扱えるようになった。またこれはデフォルト実装を提供しなくてもよい。

@Managed
interface MarkdownSourceSet extends LanguageSourceSet {
    boolean isGenerateIndex()
    void setGenerateIndex(boolean generateIndex)
    boolean isSmartQuotes()
    void setSmartQuotes(boolean smartQuotes)
}
class RegisterMarkdown extends RuleSource {
    @LanguageType
    void registerMarkdown(LanguageTypeBuilder<MarkdownSourceSet> builder) {
        builder.setLanguageName("Markdown")
    }
}
apply plugin: 'language-base'
apply plugin: RegisterMarkdown

model {
    md(MarkdownSourceSet) {
        generateIndex = true
    }
}

A @ComponentBinaries rule can create binaries for any ComponentSpec instance

@ComponentBinariesアノテーションをつけたクラスからバイナリーを生成できるようになったらしい…(よくわかってない)

Javaモデルの改善

テストサポート

Javaモデルは新たにソフトウェアコンポーネントとしてJUnitテストスイートを宣言できるようになった。スタンドアローンなコンポーネントあるいはテスト管理下のコンポーネントとして。詳しくはユーザーガイドを参照とのこと。

コンパイル回避の改善

今バージョンのGradleからABI(Application Binary Interface)が変更しないライブラリーを利用するライブラリーの再コンパイルを回避するようになった。バージョン2.9からはライブラリーがAPIを宣言した場合に、スタブAPIのjarファイルをGradleは生成するようになっていた。これによりABIが変更しないライブラリーを利用するライブラリーを再コンパイルを回避することができる。今バージョンのGradleではAPIを宣言しないライブラリーにもこの機能を拡大適用する。例えばライブラリーAがライブラリーBに依存している場合、次のケースで再コンパイルが必要なくなる。

  • ライブラリーBにプライベートなメソッドが追加された場合
  • ライブラリーBのメソッドの内容が変更された場合
  • ライブラリーBのメソッドの順番が変更された場合

この機能はローカルライブラリーのみに適用され、外部依存ライブラリーには適用されない。詳しくはユーザーガイドを参照。

IDE連携

GradleのIDE連携は二通りある。一つはプロジェクトファイル生成する方法ともう一つはツーリングAPIを通じたプロジェクトの読み込みである。今バージョンではこのサポートが改善された。プロジェクトファイル生成した場合はすぐに試せるが、gradleファイル読み込みの場合はIntelliJ IDEAあるいはBuildship(EclipseのGradle用プラグイン)の更新が必要となる。

生成されたIDEAのファイルにあるJavaの言語レベルが正しくなる

これまでideaプラグインで生成されるプロジェクトファイルはルートプロジェクトのsourceCompatibilityだけが考慮されていて、サブプロジェクトは考慮されていなかった。これが修正されてすべてのサブプロジェクトのsourceCompatibilityの中で最も高いものが言語レベルとして設定される。なおDSLにてidea.project.languageLevelが設定されていた場合はssourceCompatibilityは考慮されない。言語レベルとして設定された値はiprファイル、imlファイルを生成するときに使われる。またツーリングAPIから取得する場合にも利用される。

IntelliJ IDEAにツーリングAPIからJavaの設定情報が渡される

ツーリングAPIはGradleビルドがIntelliJ IDEAに取り込まれた時に、IdeaProjectモデルおよびIdeaModuleモデルを提示するようになる。これらのモデルにはJavaの言語設定情報が含まれていなかったが、ビルドと同じ状態をIDEでも再現できるようになる。Java言語設定はIdeaProject.getJavaLanguageSettings()あるいはIdeaModule.getJavaLanguageSettings()から取得できるようになる。

Eclipseの.classpathファイルはJavaランタイム情報を保持するようになる

eclipseClasspathタスクで生成される.classpathファイルはEclipseのデフォルトランタイムを指示していたが、具体的にJavaランタイムのバージョンを指定するようになる。ランタイムの名前はEclipseのデフォルトの方法に従い、javaプラグインのtargetCompatibilityの値からJavaランタイムの名称を決定するようになる。

ランタイムの名称を変更する場合はEclipseのjdtモデルにあるjavaRuntimeNameの値を用いる。

eclipse {
  jdt {
    javaRuntimeName = "JavaSE-1.8"
  }
}

ツーリングAPIからEclipseにJava言語設定に関してより多くの情報が渡されるようになる

ターゲットとなるバイトコードのバージョン情報がeclipseに渡されるようになる。

これらEclipseに関する変更はBuildshipの次のバージョンから利用可能になる。

コンティニュアスビルドによるファイルの自動変更検知

Gradle2.5以来のコンティニュアスビルドはビルド終了後にファイル変更を検知していたが、今バージョンからはビルド途中でもファイルの変更を検知して再ビルドする。

TestNGの実行順序サポート

preserveOrderおよびgroupByInstancesの２つのプロパティによってテスト実行順序を制御できるようになる。詳しくはマニュアルを参照。

test {
  useTestNG {
    preserveOrder true
    groupByInstances true
  }
}

Javaプロジェクト新規作成時のテスティングフレームワーク選択

initタスクでGradleプロジェクトを作る際にテスティングフレームワークとしてJUnitの代わりにSpockあるいはTestNGを指定することができるようになった。以下のとおり指定する。

gradle init --type java-library --test-framework spock
gradle init --type java-library --test-framework testng

Ivyディスクリプター生成時のexcludeサポート

GradleのIvyパブリッシュプラグインでivy形式のアーティファクトを発行できるが、今回のリリースでexcludeする依存性の情報をivy.xmlファイルに出力することが可能になった。

TwirlのJavaデフォルトインポート

GradleのPlayプラグインではTwirlテンプレートのコンパイルができるわけだが、Scalaのデフォルトインポートが使われると考えていたが、それをJavaのデフォルトインポートを使うかデベロッパーが選択できるようになった。

model {
  components {
    play {
      twirlTemplates {
        defaultImports = TwirlImports.JAVA
      }
    }
  }
}

Separate convention plugins for native unit testing

Playスタンドアローン版配布の修正

バグ修正

非推奨になったやつ

ビルドが壊れる可能性のあるもの

既知の問題