[operation:2182] Re: Hudsonのテスト環境試用のお願い

[Jun Futagawa]

ふたがわです。

On 2008/11/12 9:55,Kohsuke Kawaguchi wrote:

>>>> 他の良い方法があれば書き変えていただけると嬉しいです。
>>> Maven 弱者なので同じくです．
>> 一昨日からHudsonのビルドが上手くいかず、
>> 先程id:ashigeru(ありがとう)にマルチモジュールという仕組みを教えていただき、
>> やっとビルド・起動してデバッグできるようになりました。
>> そして、長いこと無視していた M2_REPO の意味も今頃知りました。
>> Maven 強者になるのはとても難しいです。
> 
> Hudsonの方でエラーの検出や診断で改善が出きるところがあれば知りたいので、
> もしこのあたりのうまくいかなかった経緯を教えて下さると大変参考になります。

基本的に僕の知識不足だっただけでHudsonの問題ではないです(^^;;。

これまでEclipseでMaven使う時は m2eclipse というPluginに頼ってたせいで、
Mavenのコマンドの使い方をあまり知らなかったこともあり、素直に下記の
Building Hudsonに従わなかったのが大きな間違いでした。
http://hudson.gotdns.com/wiki/display/HUDSON/Building+Hudson

参考になるか判りませんが、うまくいかずにはまった点は次のとおりです。
(いろいろ教えてくださった id:shigeru さんありがとうございます)

1. 1つのプロジェクト + Eclipseのプロジェクト設定でどうにかしようとして
　　コンパイル出来なかった

Eclipse PluginのSubversiveで
https://hudson.dev.java.net/svn/hudson/trunk/hudson/
をチェックアウトし、マルチモジュールというのを知らなかったので、
プロジェクトのJava Build Pathに必要そうな
main\core\src\main\java
main\maven-agent\src\main\java
などを追加していったものの
cannot be resolved to a type
などでコンパイルが通らなかった。

-> マルチモジュールだということを教えていただき
　mvn eclipse:clean eclipse:eclipse process-resources
　を実行して、モジュールごとのプロジェクト設定を生成・インポートして解決

これまで他のOSSのコードを見る時も適当に手動で設定してコンパイルを
通していたので、手動で設定するのがいつも面倒だと思っていましたが、
僕が間違った使い方をしているだけだということが判りました。

2. Eclipseへのモジュール単位でのImport

Subversiveでチェックアウトしていたので、hudson 直下に .project が作られており、
Import -> Existing Projects into Workspace -> Select root directory で
hudson フォルダを指定してもそれ以下のモジュールが自動検出されませんでした。

-> hudson 直下の .project ファイルを削除してImportし直しで解決
　今回初めてImportが指定したフォルダ以下のプロジェクトを
　自動検出してくれることを知りました。

3. mvn install 時にテストが失敗

-> mvn -Dmaven.test.skip=true install して解決
　あまり良い方法ではないと思いますが、とりあえずデバッグ起動に必要な
　Pluginを入れたかったのでテストなしでローカルリポジトリに入れました。
　今回初めて mvn install コマンドを使いました。

4. M2_REPO の環境変数をEclipseに設定していなかった

これまでMavenの依存ライブラリは m2eclipse が自動的に作ってくれる
Maven Dependencies を使っていたので、mvn eclipse:eclipse がM2_REPOを
使った依存ライブラリ用の設定を生成してくれることを知りませんでした。

-> Eclipse の Classpath Variables に M2_REPO を追加
　Preferences -> Java -> Build Path -> Classpath Variables
　　Name: M2_REPO
　　Path: E:/Java/Resource/Maven/repository
　　(C:\Users\ユーザ名\.m2\settings.xml で下記の設定をしている)

<?xml version="1.0" encoding="UTF-8"?>
<settings>
  <localRepository>E:\Java\Resource\Maven\repository</localRepository>
</settings>

5. Eclipse で hudson-core の hudson.model.Job がコンパイルエラー

# エラー内容
Cannot perform instanceof check against parameterized type ChartLabel. Use instead its raw form ChartLabel since generic type information will be erased at runtime Job.java hudson-core/src/main/java/hudson/model line 1002 Java Problem

# 該当箇所
public boolean equals(Object o) {
    if(!(o instanceof ChartLabel))  return false; // <- ここがエラー
    ChartLabel that = (ChartLabel) o;
    return run == that.run;
}

-> さっぱり原因が判らなかったので id:shigeru さんに教えてもらい解決

Job.createBuildTimeTrendChart() 関数内でインナークラスになっている 
class ChartLabel を関数の外にプライベートインナークラスとして宣言し、
equals関数を次のように修正

public boolean equals(Object o) {
    if(!(o instanceof Job.ChartLabel))  return false; // <- ここを修正
    ChartLabel that = (ChartLabel) o;
    return run == that.run;
}

id:shigeru さんはコンパイラにとても詳しい方で、Eclipseの内蔵コンパイラは
Genericsの言語仕様により厳密なためにエラー扱いになったのではないかと
おっしゃっていました。詳細な説明をレクチャーしていただきましたが説明
できる自信がないので省きます。

あとはDebugging Hudsonに書かれた方法でHudosonを動かしながらコードを修正し、
動きを確かめました。起動した後はJettyを再起動しなくても修正したコードが
反映され、順調に原因個所を探せました。この機能はSeasarのHot deploy
みたいな感覚で開発が出来てとても良いですね。これも初めて知りました。

以上、長くなりましたが僕がはまった点です。
はまったことでmvnコマンドの各操作の意味がちょっと判ったので、
これで他のOSSのコードを読む時もだいぶ楽になり良い知識が得られました(^^)。

-- 
ふたがわ