[B! Java][gradle] Ehrenのブックマーク

Gradleからdockerを起動して分散テストさせてみた #gradle #docker - mike-neckのブログ

昨日のエントリーの続きです。 mike-neck.hatenadiary.com Gradle万能派の僕には、納得がいかなかったので、最後までやってみることにしました。切り捨てたことまず、分散テストは何が目的なのか考えると、テスト結果をマージすることが目的なので、以下のことは切り捨てました。 dockerの外でコンパイルしたクラスファイルの共有(昨日のドハマリその2により、共有してもコンパイルしてしまうので諦めた) srcディレクトリーの共有(Javaファイルを生成するタスクがある場合はsrcディレクトリーの共有をすると、各コンテナがJavaファイル生成を行ってしまうので、諦めた) 【2015/10/20 12:19追記】つまり、コンパイル結果を共有しても再コンパイルされるので、buildディレクトリーの共有は諦めましたこの結果、妥協するのは次の点です。各コンテナでソースコード生

Ehren 2015/10/20

リンク

Gradle で JaCoCo と JMockit をいい感じに共存させる

jacoco_jmockit.gradle �a�� 0n) // 必要そうな部分のみ抜粋 // とりあえず LinkageError 例外は飛んでこない // JaCoCo apply plugin: 'jacoco' jacoco { toolVersion = "0.7.2.201409121644" } jacocoTestReport.doFirst{ classDirectories = files('build/classes/main/myproject') } // JMockit configurations { testJMockit } dependencies { testJMockit 'org.jmockit:jmockit:1.12' testCompile configurations.testJMockit.dependencies } test { j

Ehren 2015/10/15

java
gradle

リンク

Delombok using Gradle

Ehren 2015/08/04

リンク

Gradleプロジェクトで依存関係の競合を解決する | GuildWorks Blog

河上です。前回記事に載せられていなかったので改めて自己紹介を。関西に住んでフリーエンジニアをやっております。河上です。よろしくお願いします。 GradleやMavenなどでJavaのプロジェクト構成を管理していて間接的に依存しているライブラリ同士のバージョン競合が起こることってありますよね？これを「推移的な依存の競合」と呼ぶのですが、今回は単純な例で競合はどのようにして起こり、どう解決するのかを単純な例で示してみたいと思います。想定するGradleのバージョンは2.1とします。推移的な依存の競合状態の単純な例 foo:example:lib-a-1.0.0-RELEASE └bar:example:lib-x-2.0.0-REALEASE foo:example:lib-b-1.0.0-RELEASE └bar:example:lib-x-1.9.0-RELEASE 上記ではl