背景 コンパイル警告があまりに多いプロジェクトだと、最初の100件までしか警告内容が出力されない。そもそもコンパイル警告が多い状態で放置していること自体が問題だが、途中で省略させずにすべてを確認したいこともある。 $ ./gradlew clean build Starting a Gradle Daemon (subsequent builds will be faster) ... ノート:一部の入力ファイルは推奨されないAPIを追加使用またはオーバーライドしています。 ノート:入力ファイルの操作のうち、未チェックまたは安全ではないものがあります。 ノート:詳細は、-Xlint:uncheckedオプションを指定して再コンパイルしてください。 警告100個
きっかけ タスクが実行される順序を確認する タスクの依存関係を確認する 出典 きっかけ Mavenではビルドライフサイクルの中で、決められた一連のタスクが頭から流れるため、なんとなく覚えていれば「この操作の前に処理を挟みたければあのタスクだな。」等がぱっとわかると思います。 Gradleだと、タスクの自由度の高さがある一方「このタスクってどういう順で実行されるんだけ？そもそもなんでこの順になるんだっけ？」となることがあります(筆者はなりました)。 そこで、Gradleでタスクの依存関係を確認する方法を調査しました。 タスクが実行される順序を確認する gradle <タスク名> --dry-runを使用することで、どの順で何のタスクが実行されるかを表示することができます。 >./gradlew build --dry-run :compileJava SKIPPED :processReso
これは、 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
@irofさんのエントリーで、GradleでEnclosedのテストが二回実行されるんだ。 「あとではまる」とブックマークしたらば、3ヶ月後にちゃんとはまりましたｗ で、原因ですが、Groovyでコンパイルされた後のネストクラスが、トップレベルのクラスとして認識されるため、Eclosedで実行され、かつ通常のJUnitテストとして実行されるのが、おそらくは原因。 回避策は2つ。 1つはEnclosedテストランナーを利用しないｗ というか、@RunWithの部分をコメントアウトすればOK。 もう一つは、テストの実行時に除外クラスを指定すること。つまり、build.gradle に次のように設定する。 test { exclude '**/*$*' } ネストクラスやインナークラスは、「アウタークラス$インナークラス」となるため、$で判断してます。 exclude '**/*Test$*'
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く