BlogJavaを中心にした技術ネタなど。セキュリティ対策は理解できるけども...情報セキュリティが叫ばれ始めて久しい昨今、ソフトウェア開発の現場も随分厳しくなってきました。インターネットが自由に(もちろん、業務利用だけですよ)できる現場はほとんどないんじゃないでしょうか。インターネットに繋がってない(つまり、イントラだけ)と言う現場もありますね。あとはフリーウェアの導入も制限されることも少なくないですね。僕も使い慣れたフリーウェアがあって、やっぱりこれらがないと作業しにくいんですよね。TortoiseSVN(ファイルバージョン管理ツール)WinMerge(DIFFツール)これらがないと不便でしょうがない。小~中堅ソフト会社内の順で制約が厳しい。ユーザ企業に常駐するより、持ち帰り案件をソフト会社内で開発しているほうが、仕事はやりやすいかな。組み合わせで、JUnitテストを書くと、APサーバが起動しなくなる問題が。Platform)を使って、Webアプリ開発をしている。2ビルドツールとしてMaven2を使用しており、pom.xmlで以下のようにJUnitを"テスト時のみ"クラスパスに通している。--></dependency>3ソースコードの配置場所と、コンパイルされたclassファイルの出力先は、Maven2の仕様にしたがっている。junit/framework/TestCaseが発生し、Webアプリが実行できない。JUnitテストクラスをロードしてしまっている。Webアプリ実行時にはクラスパスに追加されていない。発生する、と言う理屈です。対処としては、WTPにJUnitテストクラスをロードさせないようにします。GANYMEDEでは、そのような設定をする操作は見つけられなかったので、WTPの設定ファイルを直接編集してしまう。以下のようになっています。</project-modules>この7行目と8行目が余計なので削除すると、無事にWebアプリが起動するようになります。本来実行時には必要のないライブラリが組み込まれてしまうことになるので、よろしくないです。言えば、良く使われている組み合わせと思うのですが、なぜかWeb上にも同様の現象についての情報はないようで。javadoc:javadoc)すると、コンパイルエラーが発生しました。JUnitのTestCaseを継承して、独自のTestCaseを作成し、JavaDocを生成しようとすると。シンボルを見つけられません。com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:65)-----------------------------------------JavaDoc生成以外では、Maven2からでも、Eclipse上でもコンパイルが通っているのに、なぜかJavaDoc生成時にJUnitのTestCaseクラスが見つからず、コンパイルエラーになってしまいます。---<dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>3.8.1</version><scope>test</scope></dependency>-------------------のようにJUnitライブラリを追加していたことでした。JUnitなので、テスト時にしか使わないだろうと言うことでスコープをtestにしていました。testスコープのライブラリは、ユニットテストのコンパイルと実行にしか使用されません。¥src¥test¥java下ではなく、¥src¥main¥java下に配置していた...つまり、ユニットテストではないので、testスコープの範囲外と言うことで、JavaDoc生成時にJUnitライブラリがクラスパスに設定されないようです。---<dependency><groupId>junit</groupId><artifactId>junit</artifactId><version>3.8.1</version><scope>provided</scope></dependency>-------------------のように、providedにしました。これならコンパイルも通るようになるし、実行モジュールにJUnitが入ってしまうこともありません。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等は含めないことが多いと思いますが)なお、これらのファイルに特定の環境に依存する値(絶対パスなど)が書かれていないのが、再配布可能にするミソです。特別な設定をしなくても開発できるはずです。以上で、快適な開発環境ができる...と思います。コメント:0(続)Maven2のブラックリストに載ってしまったリポジトリを復活させるには以前の記事「Maven2のブラックリストに載ってしまったリポジトリを復活させるには」で、Maven2のブラックリストについて書きましたが、その後、色々とわかりました。ブラックリスト(注:mirrorリポジトリと言うのは単なる例で実在しません)のように...と思っていたのですが、そうではなく、アーティファクト単位で管理されているようです。・アーティファクトmaven-surefire-pluginは、centralリポジトリからダウンロードOK・アーティファクトmaven-surefire-pluginは、mirrorリポジトリからダウンロードNG(ブラックリスト)のような感じになっているようです。一般のライブラリは関係ないようです。リポジトリのダウンやネットワーク障害でアーティファクトのダウンロードに失敗した場合...・プラグインブラックリストに載る。リポジトリやネットワークが復旧しても、ブラックリストをクリア(後述)しない限りダウンロードされない。・ライブラリブラックリストに載らない。リポジトリやネットワークが復旧すれば、自動的にダウンロードされる。3.ブラックリストの実体ブラックリストの実体は、ブラックリスト用のファイルが存在するのではなく、ローカルリポジトリのプラグインディレクトリの中にある「maven-metadata-リポジトリID.xml」と言うファイルで、その内容によってブラックリストか否かを判断するようです。encoding="UTF-8"?><metadata><groupId>org.apache.maven.plugins</groupId><artifactId>maven-surefire-plugin</artifactId></metadata>----------------------------------のような違いがあります。4.ブラックリストのクリア上述のように、ブラックリストの実体は「maven-metadata-リポジトリID.xml」なので、ブラックリストをクリアするには、このファイルをバサッと消してやれば良いです。問題は、ローカルリポジトリ内にたくさんある同ファイルの、どれを削除すれば良いか?です。いちいちファイルを開いて中身を確認していられません。これに対する鍵は、Maven実行時のログです。foundのようなログが出力されるはずなので、この表示を手掛かりにブラックリスト化されているプラグインを特定し、ローカルリポジトリの下を探せば良いわけです。コメント:0次のページプロフィールAuthor:crossroad関西在住。フリーランスのソフトウェアエンジニア。エレキベース(Rock&Roll)とお酒が好物でございます。