1. 無料アクセス解析

crossroad's Blog

Javaを中心にした技術ネタなど。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

セキュリティ対策は理解できるけども...


情報セキュリティが叫ばれ始めて久しい昨今、
ソフトウェア開発の現場も随分厳しくなってきました。


インターネットが自由に(もちろん、業務利用だけですよ)できる現場は
ほとんどないんじゃないでしょうか。
運用ルールやプロキシサーバで制限されているくらいならともかく、
全くインターネットに繋がってない(つまり、イントラだけ)と言う現場もありますね。


あとはフリーウェアの導入も制限されることも少なくないですね。
僕も使い慣れたフリーウェアがあって、やっぱりこれらがないと
作業しにくいんですよね。

 Opera(ブラウザ)
 Thunderbird(メーラ)
 Meadow, xyzzy, サクラエディタ(テキストエディタ)
 Explzh(圧縮解凍ツール)
 Cygwin(Unixツール)
 ペースター(クリップボード拡張)
 CraftLaunch(アプリランチャ)
 FreeMind(マインドマップツール)
 JUDE(UMLモデリングツール)
 Trac or Redmine(チケット管理ツール)
 Subversion & TortoiseSVN(ファイルバージョン管理ツール)
 WinMerge(DIFFツール)

これらがないと不便でしょうがない。
あ、もちろんJavaの仕事やってるんで JDK と Eclipse は当然として、
Maven、Ant も必須かなぁ、と。
# ネットに繋がってないと、Mavenが使えない...


これまでの経験から言うと、作業場所が
 ユーザ企業内 > 大手SIer内 > 小~中堅ソフト会社内
の順で制約が厳しい。

なので、ユーザ企業に常駐するより、持ち帰り案件をソフト会社内で開発
しているほうが、仕事はやりやすいかな。


まぁ当然のことだし、しょうがないことですけど、
アーキテクトとして技術系の仕事に関わっていて、
技術調査が満足にできないのは、ちょっとキツ過ぎますわ...

スポンサーサイト
  1. 2009/04/14(火) 00:07:53|
  2. ソフトウェア開発 一般
  3. | トラックバック:1
  4. | コメント:0

Maven2 + WTP でJUnitテスト

Meven2 + WTP の組み合わせで、JUnitテストを書くと、APサーバが起動しなくなる問題が。

【条件】
 ①Eclipse で、WTP(Web Tools Platform)を使って、Webアプリ開発をしている。

 ②ビルドツールとしてMaven2を使用しており、pom.xmlで以下のようにJUnitを"テスト時のみ"クラスパスに通している。
  <dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>3.8.2</version>
    <scope>test</scope> <!-- スコープにtestを指定している! -->
  </dependency>

 ③ソースコードの配置場所と、コンパイルされたclassファイルの出力先は、Maven2の仕様にしたがっている。
  ・アプリのソースコード src/main/java → classファイルは target/classes に出力
  ・JUnitのソースコード src/test/java → classファイルは target/test-classes に出力


【現象】
 ・WTPからサーバを起動すると、
   NoClassDefFoundError: junit/framework/TestCase
  が発生し、Webアプリが実行できない。

 ・作成したJUnitテストクラスを削除すると、実行できるようになる。


【原因】
 直接的な原因は2つ。
 ・WTPが、Webアプリ実行時に JUnitテストクラスをロードしてしまっている。
 ・JUnitライブラリのスコープが "test" なので、Webアプリ実行時にはクラスパスに追加されていない。

 つまり、JUnitテストクラスをロードしたが、JUnitライブラリがクラスパス上にないので NoClassDefFoundError が発生する、と言う理屈です。


【対処】
 対処としては、WTPにJUnitテストクラスをロードさせないようにします。
 。。。が、Eclipse GANYMEDEでは、そのような設定をする操作は見つけられなかったので、
 WTPの設定ファイルを直接編集してしまう。

 プロジェクトルート/.settings/org.eclipse.wst.common.component を開くと、
 以下のようになっています。

 1: <?xml version="1.0" encoding="UTF-8"?>
 2: <project-modules id="moduleCoreId" project-version="1.5.0">
 3:  <wb-module deploy-name="example">
 4:   <wb-resource deploy-path="/" source-path="/src/main/webapp"/>
 5:   <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/resources"/>
 6:   <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/main/java"/>
 7:   <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/java"/>
 8:   <wb-resource deploy-path="/WEB-INF/classes" source-path="/src/test/resources"/>

 9:   <property name="context-root" value="example"/>
 10:   <property name="java-output-path"/>
 11:  </wb-module>
 12: </project-modules>

 この7行目と8行目が余計なので削除すると、無事にWebアプリが起動するようになります。

 別の方法としては、前出のpom.xmlでスコープをcompileにしても起動はするが、
 本来実行時には必要のないライブラリが組み込まれてしまうことになるので、よろしくないです。


しかし、Maven2 + WTP + JUnitテスト と言えば、良く使われている組み合わせと思うのですが、
なぜかWeb上にも同様の現象についての情報はないようで。。。おかしいなぁ。

  1. 2008/07/17(木) 22:22:43|
  2. ソフトウェア開発 Java
  3. | トラックバック:0
  4. | コメント:0

Maven2のjavadoc生成でコンパイルエラー

Maven2 でJavaDocを生成(mvn javadoc:javadoc)すると、
コンパイルエラーが発生しました。


例えば、JUnitのTestCaseを継承して、独自のTestCaseを作成し、JavaDocを生成しようとすると。。。


-----------------------------------------
> mvn javadoc:javadoc
  :
パッケージ foo.bar.test のソースファイルを読み込んでいます...
Javadoc 情報を構築しています...
標準 Doclet バージョン 1.5.0_11
全パッケージとクラスの階層ツリーを作成しています...
警告 3 個
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------

C:¥eclipse¥workspace¥foo¥src¥main
¥java¥foo¥bar¥test¥FooTestCase.javaa:23: シンボルを見つけられません。
シンボル: クラス TestCase
public abstract class FooTestCase extends TestCase {
                     ^

java.lang.NullPointerException
at com.sun.tools.javadoc.TypeMaker.getType(TypeMaker.java:65)
-----------------------------------------



JavaDoc生成以外では、Maven2からでも、Eclipse上でもコンパイルが通っているのに、
なぜかJavaDoc生成時にJUnitのTestCaseクラスが見つからず、コンパイルエラーになってしまいます。


原因は、pom.xmlの依存関係のスコープで、
--- pom.xml(抜粋) ---
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
-------------------
のようにJUnitライブラリを追加していたことでした。

JUnitなので、テスト時にしか使わないだろうと言うことでスコープをtestにしていました。
# testスコープのライブラリは、ユニットテストのコンパイルと実行にしか使用されません。(参考

ところが、JUnitを拡張して作成したクラスFooTestCaseは、
¥src¥test¥java下ではなく、¥src¥main¥java下に配置
していた...
つまり、ユニットテストではないので、testスコープの範囲外と言うことで、
JavaDoc生成時にJUnitライブラリがクラスパスに設定されないようです。


対応としては、pom.xmlで、JUnitのスコープを修正すれば良いのですが、
compileスコープにしてしまうと、実行モジュールにJUnitがバンドルされてしまう
(*.warの/WEB-INF/libに入ってしまう等)ので、

--- pom.xml(抜粋) ---
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>provided</scope>
</dependency>
-------------------
のように、providedにしました。

これならコンパイルも通るようになるし、実行モジュールにJUnitが入ってしまうこともありません。




  1. 2007/10/22(月) 23:11:59|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:0

Eclipse + Maven2 + Tomcat + Seasar2 の開発環境ベスト!?プラクティス

昨今、良くある(僕自身も好みの)組み合わせで、
 ・IDE・・・Eclipse
 ・ビルドツール・・・Maven2 及び Eclipse m2eclipseプラグイン
 ・コンテナ・・・Tomcat 及び Tomcatプラグイン
 ・フレームワーク・・・Seasar2 及び S2ファミリー
と言うのがあります。

しかし、開発環境構築は結構難問です。
Eclipse、Maven2、m2eclipse、Tomcatプラグイン...
それぞれ「個別の問題」にフォーカスしたツールを組み合わせようとすると、
細かいところでギャップがあって、各ツールの長所を活かしつつ、うまく連携させるには試行錯誤が必要です。


そこで、以下のような各ツールの長所を活かせる開発環境を作ってみる。

 1.Eclipse
  ・修正したソースのインクリメンタルコンパイル
  ・その他もろもろ...

 2.Maven2
  ・pom.xmlによるプロジェクトメタ情報の定義、一元管理
  ・ビルドの標準化

 3.m2eclipseプラグイン
  ・pom.xmlの依存ライブラリを修正するだけで、
   ライブラリのダウンロード、Eclipseビルドパスを自動更新

   (依存ライブラリを修正するたびに mvn eclipse:eclipse しなくて良い!)

 4.Tomcatプラグイン
  ・Eclipse上でTomcatの起動/停止。
  ・デバッグが簡単。(リモートデバッグしなくて良い!)
  ・DevLoaderを使えば、Warモジュールを作成することなく、
   修正したソースをTomcatに即反映可能


 5.Seasar2 2.4.xのSMART Deploy
  ・HOT deployで、Tomcat(のコンテキスト)を再起動することなく
   修正したソースをTomcatに反映可能

   Seasar2 2.4.x以上が必須になります。

つまり、
必要なライブラリは自動設定されて、修正したソースはTomcatに即反映されて、
Tomcat上でデバッグもできて、Mavenで一貫したビルドもでき、
しかも開発者ひとりひとりの手間を極力省くことができる、環境なのです!!(のはず)


では作り方。
ちなみに、この作業はアーキテクトだけが行う初期作業です。

 1.Eclipse
  特に特別な手順はありません。

 2.Maven2
  ①pom.xmlを書きます。
   maven-eclipse-pluginの設定で、downloadSourcesとdownloadJavadocsをtrueにしておきます。

  ②Eclipseのプロジェクト作成ウィザードを使うのが面倒なので、
   初回だけ「mvn eclipse:eclipse」でEclipseプロジェクトを作成し、Eclipseにインポートします。
   この時点では、クラスパス変数M2_REPOが未定義なので、ビルドエラーになります

  ③プロジェクトのプロパティ、Javaビルドパスから「M2_REPO/~」を
   全て削除します。当然、ビルドエラーになりますが、ここでは無視します。

 3.m2eclipseプラグイン
  ①m2eclipseをインストール。

  ②Eclipseの設定のMaven2で、ソースのダウンロードと、JavaDocのダウンロード
   を有効(チェックON)
にしておきます。

  ③プロジェクトを右クリック→Maven2 で、Maven2特性を有効にします。
   Maven2 Dependenciesと言うクラスパスコンテナが作成されます。
   この時点でビルドが通るはずです。

   これ以降は、pom.xmlを修正すればライブラリのダウンロード~ビルドパス設定が
   自動的に行われます。
   mvn eclipse:eclipse でビルドパスを更新する必要はありません

 4.Tomcatプラグイン
  ①Tomcatプラグインをインストールし、基本設定。
   
  ②dragon3さんが公開している改変版DevLoaderを入手し、
   Tomcatにセットアップ。

   TomcatプラグインにバンドルされているオリジナルのDevLoaderを使うと、
   pom.xmlにservlet-api-xxx.jarへの依存性が含まれていると実行時にClassCastExceptionが発生
します。
   逆に言えば、Servlet API を使わなければ、オリジナルのDevLoaderでも構いませんが、
   Servlet APIを使わないということは少ないのかなと思います。

  ③プロジェクトのプロパティ、Tomcatで以下の通り設定。
   ・Tomcatプロジェクト・・・ON。
   ・コンテキスト名・・・任意の名前を入力。
   ・コンテキスト定義の更新を可能にする・・・ON。
   ・このコンテキストを再読込可能にする・・・OFF
    (ONにすると、ソースを修正するたびにコンテキストが再起動してしまいます)
   ・Webアプリケーション・ルートとするサブディレクトリ・・・main/src/webapp
   ・開発用クラスローダを有効にする・・・ON
    /PROJECT_NAME/target/classes
    org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER をチェックON。
    (個々のライブラリをチェックONにしてしまうと、.tomcatpluginに絶対パスが書かれてしまい、再配布できません)

 5.Seasar2
  env.txt で、開発時はHOT Deployが有効になるようにしておきます。
  こうすることで、コンテキストを再起動することなく、修正したソースをTomcatに即反映できます。

 6.配布
  pom.xml.classpath.project.tomcatplugin を含めて、プロジェクトを配布(CVSやSVNにコミット)します。
  (通常はpom.xmlだけで、.classpath等は含めないことが多いと思いますが)

  なお、これらのファイルに特定の環境に依存する値(絶対パスなど)が書かれていないのが、再配布可能にするミソです。

  各開発者は、配布されたプロジェクトをEclipseにインポートするだけで、
  特別な設定をしなくても開発できる
はずです。


以上で、快適な開発環境ができる...と思います。

一応、ざっくりと動作確認していますが、うまくいかなかった場合はご容赦をm(_ _)m


テーマ:プログラミング - ジャンル:コンピュータ

  1. 2007/10/16(火) 00:18:07|
  2. ソフトウェア開発 Java
  3. | トラックバック:1
  4. | コメント:0

(続)Maven2のブラックリストに載ってしまったリポジトリを復活させるには

以前の記事「Maven2のブラックリストに載ってしまったリポジトリを復活させるには」で、
Maven2のブラックリストについて書きましたが、その後、色々とわかりました。

1.ブラックリストは、アーティファクト単位に管理される
 当初、ブラックリストはリポジトリ単位で管理されている...例えば、
  ・centralリポジトリ はOK
  ・mirrorリポジトリ はブラックリスト(注:mirrorリポジトリと言うのは単なる例で実在しません)
 のように...と思っていたのですが、そうではなく、
 アーティファクト単位で管理されているようです。

 つまり、
  ・アーティファクトmaven-surefire-pluginは、centralリポジトリからダウンロードOK
  ・アーティファクトmaven-surefire-pluginは、mirrorリポジトリからダウンロードNG(ブラックリスト)
 のような感じになっているようです。

2.ブラックリストに載るのはプラグインだけ
 ブラックリストが管理されるアーティファクトは、プラグインだけで、
 一般のライブラリは関係ない
ようです。

 つまり、例えばリポジトリのダウンやネットワーク障害でアーティファクトの
 ダウンロードに失敗した場合...
  ・プラグイン
   ブラックリストに載る
   リポジトリやネットワークが復旧しても、ブラックリストをクリア(後述)しない限り
   ダウンロードされない

  ・ライブラリ
   ブラックリストに載らない
   リポジトリやネットワークが復旧すれば、自動的にダウンロードされる。
 と言うことになります。

3.ブラックリストの実体
 ブラックリストの実体は、ブラックリスト用のファイルが存在するのではなく、
 ローカルリポジトリのプラグインディレクトリの中にある「maven-metadata-リポジトリID.xml」
 と言うファイル
で、その内容によってブラックリストか否かを判断するようです。

 たとえば、M2_REPO/org/apache/maven/plugins/maven-surefire-plugin/maven-metadata-central.xml を見ると...

 ・通常(ダウンロード成功)時
  ----------------------------------
  <?xml version="1.0" encoding="UTF-8"?>
  <metadata>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
   <version>2.1.3</version>
   <versioning>
    <latest>2.3</latest>
    <release>2.3</release>
    <versions>
     <version>2.0-beta-1</version>
        :
     <version>2.3</version>
    </versions>
    <lastUpdated>20070301014816</lastUpdated>
   </versioning>
  </metadata>
  ----------------------------------


 ・ブラックリスト時
  ----------------------------------
  <?xml version="1.0" encoding="UTF-8"?>
  <metadata>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-surefire-plugin</artifactId>
  </metadata>
  ----------------------------------

 のような違いがあります。

4.ブラックリストのクリア
 上述のように、ブラックリストの実体は「maven-metadata-リポジトリID.xml」なので、
 ブラックリストをクリアするには、このファイルをバサッと消してやれば良いです。

 問題は、ローカルリポジトリ内にたくさんある同ファイルの、どれを削除すれば良いか?です。
 いちいちファイルを開いて中身を確認していられません。

 これに対する鍵は、Maven実行時のログです。
 ブラックリスト化されたプラグインが原因でMavenの実行に失敗すれば、

  [INFO] Repository 'central' will be blacklisted
  [INFO] ------------------------------------------------------------------------
  [ERROR] BUILD ERROR
  [INFO] ------------------------------------------------------------------------
  [INFO] The plugin 'org.apache.maven.plugins:maven-surefire-plugin' does not exist or no valid version could be found

 のようなログが出力されるはずなので、この表示を手掛かりにブラックリスト化されている
 プラグインを特定し、ローカルリポジトリの下を探せば良いわけです。


と、こんなところです。
いまいち、なぜこのような仕組みが導入されたのか良くわかりませんが...

テーマ:プログラミング - ジャンル:コンピュータ

  1. 2007/10/11(木) 23:11:08|
  2. ソフトウェア開発 Maven
  3. | トラックバック:0
  4. | コメント:0
次のページ

プロフィール

crossroad

Author:crossroad
関西在住。男。
フリーランスのソフトウェアエンジニア。
エレキベース(Rock&Roll)とお酒が好物でございます。

カテゴリー

タグリスト

Java F1 フリーランス ベーシスト HARRY TheStreetSliders iPhone FX お酒 Seasar Maven eclipse Wicket マイホーム 野球 プロジェクトファシリテーション Rails Ruby UML お店 ソフトウェア Tomcat S2Flex2 jsf Teeda Eclipse タグライブラリ ajax タスク europa mylyn trac 

ブログ内検索

最近の記事

最近のコメント

最近のトラックバック

カレンダー

07 | 2017/08 | 09
- - 1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31 - -

月別アーカイブ

全ての記事を表示する

全ての記事を表示する

Twitter


RSSフィード

リンク

このブログをリンクに追加する

アクセスカウンタ

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。