コーヒーブレイク(ディレクトリ構造---ちょっぴりMaven)

ここで書くことは、私自身、迷っていますし、未だに結論を出せないでいます。したがって、ベストではない方法を採用する可能性もあります。 もし何か、もっと良い提案があったら、ご連絡下さい(もしかしたら多分に趣味的な側面、それからいくつかの点がトレードオフになっているわけで、どこに重点を置くかということかもしれませんが)

もともと何が標準なのか、ということは難しいのですが、以前よりwebアプリケーションのディレクトリ構造をどうしようか、と 迷っていました。今回Cactusやら、ここには書きませんがmavenなどをいじっているうちに、今までの僕のやっているディレクトリー構造は ちょっと違うのかな、と思いました。これは、けっしてめちゃめちゃ変だというわけではないし、eclipseでTomcatプロジェクトを作った 場合の標準なのですから。

しかし、テストのソースは、或いはコンパイルされたclassファイルは、少なくとも実際のアプリケーションの中にはいるものではありません。

さらに、cvsで管理する際も今編集しているwebアプリケーションがそのままcvsに登録されているものと全く同じ、 というのも問題があるのかもしれません。

少々抽象的なので、もう少し具体的に話しをすると、現在はほぼ次のようなディレクトリー構造をしています。

/webcms
 └ /WEB-INF
    ├ /classes
　　｜  ├ /Resources
　　｜  └ /com
　　｜　     ├ /chikkun
　　｜　     ├ /common
　　｜　     └ /webcms
　　｜　        　  ├ /test
　　｜　        　  └ /test2
　　｜
　　├ /conf
　　├ /database
　　├ /jsp
　　├ /lib
　　├ /merge
　　└ /src
    　  └ /com
    　     ├ /chikkun
    　        ├ /common
    　        └ /webcms
    　        　  ├ /test
    　        　  └ /test2

                  

これに対して、mavenでstrutsのプロジェクトを作ると、以下のようなディレクトリ構造が自動的に作られます。

/webcms
 ├ /src
 │  ├ /conf
 │  ├ /java
 │  │  └ /com
 │  │  　  └ /chikkun
 │  │  　  　  └ /webcms
 │  ├ /merge
 │  ├ /test
 │  │  └ /com
 │  │  　  └ /chikkun
 │  │  　  　  └ /webcms
 │  ├ /test-cactus
 │  │  └ /com
 │  │  　  └ /chikkun
 │  │  　  　  └ /webcms
 │  │  　  　  　  ├ HttpUnitTest.java
 │  │  　  　  　  └ StrutsTest.java
 │  └ /webapp
 │  　  └ /WEB-INF
 │  　  　  └ /jsp
 └ /target
 　  ├ /classes
 　  │  └ /com
 　  │  　  └ /chikkun
 　  │  　  　  └ /webcms
 　  ├ /test-classes
 　  │  └ /com
 　  │  　  └ /chikkun
 　  │  　  　  └ /webcms
 　  ├ /test-reports
 　  ├ /webcms
 　  │  └ /WEB-INF
 　  │  　  └ /tld
 　  │  　  　  └ taglib.tld
 　  └ /xdoclet
 　  　  └ /webdoclet
 　  　  　  └ /WEB-INF
 　  　  　  　  ├ struts-config.xml
 　  　  　  　  ├ validation.xml
 　  　  　  　  ├ /classes
 　  　  　  　  │  └ /com
 　  　  　  　  │  　  └ /chikkun
 　  　  　  　  │  　  　  └ /webcms
 　  　  　  　  ├ /jsp
 　  　  　  　  │  └ input.jsp
 　  　  　  　  ├ /lib
 　  　  　  　  └ /tld

                  

それから、今回あとで説明するであろうCactusに含まれているsampleのディレクトリ構造は

/servlet
 ├ /dist
 │  └ cactus-sample-servlet.war
 ├ /lib
 ├ /src
 │  ├ /conf
 │  ├ /java
 │  │  └ /org
 │  │  　  └ /apache
 │  │  　  　  └ /cactus
 │  │  　  　  　  └ /sample
 │  │  　  　  　  　  └ /servlet
 │  │  　  　  　  　  　  └ /util
 │  ├ /test-cactus
 │  │  └ /org
 │  │  　  └ /apache
 │  │  　  　  └ /cactus
 │  │  　  　  　  └ /sample
 │  │  　  　  　  　  └ /servlet
 │  │  　  　  　  　  　  └ /unit
 │  └ /webapp
 │  　  ├ cactus-report.xsl
 │  　  ├ /test
 │  　  └ /WEB-INF
 │  　  　  ├ cactus-web.xml
 │  　  　  └ web.xml
 └ /target
 　  ├ /classes
 　  │  ├ /cactus
 　  │  │  └ /org
 　  │  │  　  └ /apache
 　  │  │  　  　  └ /cactus
 　  │  │  　  　  　  └ /sample
 　  │  │  　  　  　  　  └ /servlet
 　  │  │  　  　  　  　  　  └ /unit
 　  │  └ /java
 　  │  　  └ /org
 　  │  　  　  └ /apache
 　  │  　  　  　  └ /cactus
 　  │  　  　  　  　  └ /sample
 　  │  　  　  　  　  　  └ /servlet
 　  │  　  　  　  　  　  　  └ /util
 　  └ /test-reports
 　  　  └ /tomcat5x


            

eclipseのプロジェクトで作った、私がずっと使っていた1番上のディレクトリ構造は、そのままTomcatにそのままdeployするディレクトリー構造になっています。これのメリットは

1. そのままTomcatにデプロイできるわけですので、同時に、そのままeclipseの中からTomcatを立ち上げて、ソースを書き直すたびにすぐにその成果を確認できる。
2. eclipseで作ったプロジェクトそのままなので、何の変更も必要がないがない。

一方で、デメリットもあります。

1. ソースディレクトリーがWEB-INFの下にあるので、warファイルをそのまま作成したら、ソースも含まれてしまう。
2. 今回の話しのように、テストのソースもWEB-INF/srcを使わざるを得なく、したがって同様にwarファイル作成時にそれらのテストのクラスファイルまで含まれてしまう。

上記のことも、antなどの設定により、warファイル作成や、あるいはdeployの際に解決することは可能ですが、あまりテストと本来のソースが混ざるのは、 混乱の元になるので、少々避けたいところです。

そして、下のmavenで作ったものと、Cactusのサンプルはほぼ同じ(というかサンプル自体mavenで作ったのかもしれませんが)構造になっています。ポイントは

1. ソースのコードとコンパイルしたクラスファイルを別のディレクトリ(target)にしている。
2. 本来必要なコードとテスト用のコードも別にしている(src/javaとsrc/test-cactus)。
3. Cactusのテストと、純粋なJUnitのテストのディレクトリも分けている(src/test-cactusとsrc/test---mavenの方)。
4. distというディレクトリにwarファイルを作成する。

そこで、結論としては、小さなプロジェクトであれば、eclipseのTomcatプロジェクトタイプ、少々大きくなるようなプロジェクトであれば、mavenタイプというのが良いのではないでしょうか。 (なんだか、あまり根拠のないような、あるような・・・(--;)

先ほどから出ている、mavenっていうのを説明できるほど私は詳しくありませんが、少なくとも上記のようなプロジェクトを作成するとき、ほとんどワンコマンドで作ってくれるので、 結構便利です。

そこでmavenのダウンロードから、1.02をダウンロードしてきて、それを展開します。

MAVEN_HONEを設定します(例えば、set MAVEN_HONE=c:/maven-1.02)。そして、${MAVEN_HOME}binにパスを通します。

そして、どこぞのディレクトリでDosプロンプトになって

 some_directory>maven genapp some_directory>maven eclipse 

1番目のmaven siteではいくつかの質問がされます。

1. 最初はProject Template:strutsを入力して、リターン。
2. 2番目はアプリケーションのID(どうやらwarファイル名になるらしい):webcms
3. 3番目はアプリケーション名:webcms
4. 4番目はパッケージ名:com.chikkun.webcms

これだけ答えると、上記のmavenの「ディレクトリー構造」が自動で作られます。

それ以外に、project.xmlなどが作成され、これを修正する必要があるのですが、今回は避けます(いずれ・・・)。

上記のようなmavenのディレクトリー構造だとそのままでは、すぐにTomcatのアプリケーションとして確認できません。warファイルを作って、deployすることが必要になると思います(たぶん)。

1. ロジックは基本的に、Actionには書き込まない。
2. ロジックはJUnitを使って、チェックしながら開発する。
3. ロジックが仕上がったら、ActionやActionFormを使って、StrutsTestCaseのMock(JUnitの次の章で説明)オブジェクトでテストする。
4. 一通り上記が終わったら、StrutsTestCaseのCactusStrutsTestCaseでチェックする。
5. あとはwarを作り、deployして実際手で確認してみる。

こんな感じで開発していくというのは、どうでしょうか?

ついでに、相当いい加減ですが、コーディング規約も作ってありますので、コーディング規約も参考に!