BlogJavaを中心にした技術ネタなど。S2ファミリーと言うのがあります。開発環境構築は結構難問です。細かいところでギャップがあって、各ツールの長所を活かしつつ、うまく連携させるには試行錯誤が必要です。そこで、以下のような各ツールの長所を活かせる開発環境を作ってみる。1.Eclipse・修正したソースのインクリメンタルコンパイル。3.m2eclipseプラグイン・pom.xmlの依存ライブラリを修正するだけで、ライブラリのダウンロード、Eclipseビルドパスを自動更新。しなくて良い!)4.Tomcatプラグイン・Eclipse上でTomcatの起動/停止。修正したソースをTomcatに即反映可能。deployで、Tomcat(のコンテキスト)を再起動することなく修正したソースをTomcatに反映可能。2.4.x以上が必須になります。必要なライブラリは自動設定されて、修正したソースはTomcatに即反映されて、Tomcat上でデバッグもできて、Mavenで一貫したビルドもでき、しかも開発者ひとりひとりの手間を極力省くことができる、環境なのです!!(のはず)では作り方。ちなみに、この作業はアーキテクトだけが行う初期作業です。1.Eclipse特に特別な手順はありません。2.Maven21pom.xmlを書きます。maven-eclipse-pluginの設定で、downloadSourcesとdownloadJavadocsをtrueにしておきます。eclipse:eclipse」でEclipseプロジェクトを作成し、Eclipseにインポートします。この時点では、クラスパス変数M2_REPOが未定義なので、ビルドエラーになります。3プロジェクトのプロパティ、Javaビルドパスから「M2_REPO/~」を全て削除します。ビルドエラーになりますが、ここでは無視します。3.m2eclipseプラグイン1m2eclipseをインストール。2Eclipseの設定のMaven2で、ソースのダウンロードと、JavaDocのダウンロードを有効(チェックON)にしておきます。Maven2特性を有効にします。Dependenciesと言うクラスパスコンテナが作成されます。この時点でビルドが通るはずです。これ以降は、pom.xmlを修正すればライブラリのダウンロード~ビルドパス設定が自動的に行われます。ビルドパスを更新する必要はありません。4.Tomcatプラグイン1Tomcatプラグインをインストールし、基本設定。2dragon3さんが公開している改変版DevLoaderを入手し、Tomcatにセットアップ。TomcatプラグインにバンドルされているオリジナルのDevLoaderを使うと、pom.xmlにservlet-api-xxx.jarへの依存性が含まれていると実行時にClassCastExceptionが発生します。APIを使わないということは少ないのかなと思います。3プロジェクトのプロパティ、Tomcatで以下の通り設定。・Tomcatプロジェクト・・・ON。・コンテキスト名・・・任意の名前を入力。・コンテキスト定義の更新を可能にする・・・ON。・このコンテキストを再読込可能にする・・・OFF。(ONにすると、ソースを修正するたびにコンテキストが再起動してしまいます)・Webアプリケーション・ルートとするサブディレクトリ・・・main/src/webapp・開発用クラスローダを有効にする・・・ON。Deployが有効になるようにしておきます。することで、コンテキストを再起動することなく、修正したソースをTomcatに即反映できます。含めて、プロジェクトを配布(CVSやSVNにコミット)します。(通常はpom.xmlだけで、.classpath等は含めないことが多いと思いますが)なお、これらのファイルに特定の環境に依存する値(絶対パスなど)が書かれていないのが、再配布可能にするミソです。特別な設定をしなくても開発できるはずです。以上で、快適な開発環境ができる...と思います。5.0.xで環境を作って、簡単なプログラミングをしたのですが、ちょっとハマりました。単純なHTMLを作成。Beanと連携するわけでもない、本当にただのHTMLです。PlugIn+DevLoaderを使ってTomcat上で実行。作成したHTMLにアクセスしてみると...あらら例外発生org.seasar.teeda.core.exception.UriNotFoundRuntimeException:[ETDA0026]URI(http://www.seasar.org/teeda/extension)が見つかりませんorg.seasar.teeda.extension.config.taglib.impl.AbstractTaglibManager.getTaglibElement(AbstractTaglibManager.java:68)<以下略>うーむ、TeedaのタグライブラリのURIが見つからん、と言われています。結論から言うと、原因はDevLoaderを使っていることに起因していました。・DevLoaderを使用しているので、J2EE規定のWebアプリケーションのディレクトリ構造にしていない(※)。(WEB-INF/classesやWEB-INF/libがない)・タグライブラリのクラスやTLDファイルは、Jarファイルにまとめられていて、TLDファイルを明示的に配置していない。・Teedaその他の稼動に必要なJarファイルは、Mavenのローカルリポジトリ上にある。※DevLoaderを使うと、Webアプリ構成になっていなくてもTomcatにクラスやJarをロードさせ、Webアプリとして稼動させることができます。下にJarを置かないとTLDファイルを見つけてくれないようです。上述の通り、今回はTLDファイルを含むJarファイルが、Maven2のローカルリポジトリ上に存在するので、TLDファイルが見つからず、エラーになっているのでした。対処の方法はいくつかありそうです。PlugInDevLoader評価1TLDファイルを、WEB-INF下に配置するJarからTLDファイルを取り出し、WEB-INF下に配置します。PlugIn+DevLoaderによる効率的な開発が可能です。本来必要のないTLDファイルを配置することになってしまうのがタマに傷な気がします。使用する使用する○2TLDファイルを含むJarを、WEB-INF/lib下に配置するTLDファイルを含むJarを、Maven2ローカルリポジトリから、WEB-INF/lib下にコピーします。PlugIn+DevLoaderによる効率的な開発が可能です。Maven2でJarを一元管理しているのに、それとは別にJarを配置・管理することになり、ちょっと頂けません。PlugInのWebアプリケーションルートとして指定します。この場合は、DevLoaderを使わないので、Javaソース等を修正したらリアルタイムにTomcatに自動反映ができず、Tomcatに反映するにはWebアプリ構成を更新する必要があります。Webアプリ構成の作成・更新は、Maven2のwar:explodedゴールを使えば簡単にできますし、逆に言えば「ちょっと直しただけでいちいちTomcatがリロードしてうっとおしい」と言う事がなくなるので、むしろ利点と言えるかもしれません。PlugInはあきらめて、普通にWarモジュールを作成・デプロイします。この場合は、修正したソースを反映させるためには、Warの生成とTomcatへのデプロイが毎回ともなうので、開発効率が低下してしまいます。個人的には、3.の方法が好みかなと思います。PlugIn+DevLoaderでロードしている場合には、常に問題になるはずです。それにしても、Teeda良くできてるなぁ...素にJSFを使うと、faces-config.xmlがかなり問題になりそうですが、それもS2Containerの自動登録機能で解決。コメント:0プロフィールAuthor:crossroad関西在住。フリーランスのソフトウェアエンジニア。エレキベース(Rock&Roll)とお酒が好物でございます。