検索

• [ Prev ]
• [ Next ]
• [ Java ]

Java/Maven3/Eclipse上でサクサクWeb開発 (例:tomcat-maven-plugin) にて tomcat-maven-plugin を選択した理由に、
「実働環境はTomcatなのに、開発をJettyとすることで不要な地雷を踏み抜きそうな悪寒がした。」
と書きましたが、今思い出しました。

実際に地雷を踏み抜いていたから、わざわざTomcatを選んだのでした。

その理由は簡単で、javax.servlet.ServletContext#getRealPath("/") が返す文字列が、Tomcatの場合末尾が '/' 付きで、Jettyの場合末尾の '/' が付いてこない。で、件のEclipseプロジェクトでは

getRealPath("/") + "WEB-INF/foo/bar...";

としていたものだから（他人から引き継いだ既存プロジェクト）、Jettyに載せ替えようと思っても載せ替えられない。

実例：/work/tmp/mvntest/servlet1/src/main/webapp/WEB-INF/web.xml をdeploy

Tomcat上でのgetRealPath("/")

/work/tmp/mvntest/servlet1/src/main/webapp/

Jetty上でのgetRealPath("/")

/work/tmp/mvntest/servlet1/src/main/webapp

まぁ他にも地雷が埋まってそうだったので、素直にTomcatで打てる手が無いか探していた結果、tomcat-maven-plugin を見つけた次第です。
これだと、

getRealPath("/") + "WEB-INF/foo/bar..." 

がJettyだと

/work/tmp/mvntest/servlet1/src/main/webappWEB-INF/foo/bar...

になってしまい、ファイル操作が失敗してしまうという罠・・・。

この辺、もしかして仕様が決まってないのかな？JavaDoc確認しても、J2EE 1.3 と Java EE 6 の双方で、ディレクトリを指定した場合の末尾のPATH SEPARATORについて明確な言及がない。

• Java 2 Platform EE v1.3: Interface ServletContext
  • http://docs.oracle.com/javaee/1.3/api/javax/servlet/ServletContext.html#getRealPath(java.lang.String)
• ServletContext (Java EE 6 )
  • http://docs.oracle.com/javaee/6/api/javax/servlet/ServletContext.html#getRealPath(java.lang.String)

• [ Prev ]
• [ Next ]
• [ Up ]
• [ Java ]

• [ Prev ]
• [ Next ]
• [ Java ]

JDK 1.5 時代と 1.6 時代、さらに Mac OS X 上の Java とで、だいぶ扱いが異なってきたのでメモ。

com.sun.tools.javac.Main

• JDK 1.6 以降は javax.tools.JavaCompiler API を使うのがお作法に切り替わったようだ。
• sun.tools.javac.Main : Java Glossary
  • http://mindprod.com/jgloss/javacmain.html
• 「Java SE 6完全攻略」第89回 プログラムからコンパイル - Compiler API その1 - Java技術最前線：ITpro
  • http://itpro.nikkeibp.co.jp/article/COLUMN/20081105/318537/

tools.jar と Mac OS X

• Mac OS X のJDKでは tools.jar は単体では提供されていない。classes.jar に包含されている。
• Java Development Guide for Mac OS X: Apple Developer Tools for Java
  • http://developer.apple.com/library/mac/#documentation/Java/Conceptual/Java14Development/02-JavaDevTools/JavaDevTools.html

Maven で tools.jar を参照したい

単純な解決策：

<dependencies>  
  <dependency>  
    <groupId>com.sun</groupId>  
    <artifactId>tools</artifactId>  
    <version>1.5.0</version>  
    <scope>system</scope>  
    <systemPath>${java.home}/../lib/tools.jar</systemPath>  
  </dependency>  
</dependencies>  

Macの場合だけ除外したい：

<profiles>  
   <profile>  
     <id>windows</id>  
     <activation>  
       <os>  
         <family>windows</family>  
       </os>  
     </activation>  
     <dependencies>  
       <dependency>  
         <groupId>com.sun</groupId>  
         <artifactId>tools</artifactId>  
         <version>1.5.0</version>  
         <scope>system</scope>  
         <systemPath>${java.home}/../lib/tools.jar</systemPath>  
       </dependency>  
     </dependencies>  
   </profile>  
 </profiles>  

参考：

• m2eclipseでtools.jarが無いとかそんなことを言われた時 - tanamonの日記
  • http://d.hatena.ne.jp/tanamon/20090525/1243262079
• [maven2]tools.jarについて - hello,world
  • http://www.sorich.jp/blog/shimamura/2009/04/maven2toolsjar.html

• [ Prev ]
• [ Next ]
• [ Up ]
• [ Java ]

日記/2012/03/11/Eclipse3.7(Indigo)とm2eにMavenプロジェクトをインポートするメモ ではEclipseにMavenプロジェクトをインポートするところまでを紹介しました。
"jar"を生成するタイプのMavenプロジェクトであればm2eのおかげで"test"ゴールをEclipseからデバッグ実行できますので特に問題となることは少ないと思います。
困るのが"war"タイプのMavenプロジェクトで、デバッグ対象のServletコンテナをどこで起動するか、どうEclipseから接続するか、Maven独自のclasspathをどのように解決するか、というように解決すべき課題が多くなります。

いくつか調べた中でメリット・デメリットをまとめます。

jettyプラグインを使用

• Maven Jetty Plugin - Jetty - Codehaus (version 6系まで)
  • http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin
• Jetty/Feature/Jetty Maven Plugin - Eclipsepedia (version 7系以降)
  • http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin
• Rapid Testing Using the Jetty Plugin
  • http://maven.apache.org/plugins/maven-war-plugin/examples/rapid-testing-jetty6-plugin.html

• メリット：一番お手軽でEclipseとの親和性も高い方法です。
  • jettyのMaven用プラグインを使うと、"mvn jetty:run" で軽量Servletコンテナが立ち上がります。プラグインの方でMaven独自のソースツリーやjarの依存関係を処理してくれます。あとは"jetty:run"ゴールをEclipse上からデバッグ実行するだけです。
  • また"target/classes"やweb.xml, pom.xmlをポーリングしてくれる設定も可能で、Eclipse上からの変更を間をおかずに反映することが可能です。
• デメリット
  • 単純なwarであれば対応可能ですが、特定のServletコンテナに依存したりJ2EEサーバの機能を利用したりするような場合は適用が難しいかもしれません。

Tomcat7のVirtual webapp機能を使用

• Apache Tomcat 7 Configuration Reference (7.0.26) - The Context Container
  • http://tomcat.apache.org/tomcat-7.0-doc/config/context.html

• メリット：Tomcatコンテナ上でデバッグ実行可能です。
  • Mavenのソースツリーをそのまま使ってTomcat上にDeployすることが可能です。
  • Eclisep WTP の機能で"Server"を作成してEclipse上からデバッグ実行可能です。
  • m2eプラグインであれば、出力パスの関係から、Eclipse上で保存→コンパイル→Tomcat側でContextリロードまでがスムーズに連携するはずです。
• デメリット
  • Tomcat 7以降が必要です。
  • Mavenのjar依存関係までは解決してくれないので、Context設定に１つずつjarのフルパスを記述する必要があります。
    • メリットを覆い隠すほどのデメリットになり得るので、個人的にはあまりおすすめできない方法です。
    • 詳しくは調べていないのですが、JarScannerを設定すればもしかしたら自動スキャンとかしてくれるかも・・・？

warファイル展開用ゴールを使う

• war:exploded
  • http://maven.apache.org/plugins/maven-war-plugin/exploded-mojo.html

• メリット：一番汎用性が高い方式
  • warファイルを展開した状態のファイルツリーを生成します。
  • あとは使用するServletコンテナに応じた方法でContextを設定します。Servletコンテナのデバッグ方法については、コンテナに依存します。
    • Tomcat位ならローカルのEclipse上で動作させることができますが、WebLogicなど本格的な「重い」アプリケーションサーバ上で動かすとなると、外部サーバ上でリモードデバッグ有効で起動しておき、そちらにEclipse上からMavenでデプロイ＋リモードデバッグ接続を行うほうが良いかもしれません。
  • ほとんどのServletコンテナおよびJ2EEサーバに対応できる方式と思われます。
• デメリット
  • Eclipse上でコンパイルしただけではコンテナに反映されないため、"war:exploded"ゴールを実行＋コンテナにContextをリロードしてもらう必要があります。
  • そのため、ソースコード編集〜デバッグ実行までに若干のタイムラグが発生します。

tomcat-maven-plugin を使う

2012-04-09 追記しました。

• Java/Maven3/Eclipse上でサクサクWeb開発 (例:tomcat-maven-plugin) - Glamenv-Septzen.net
  • http://www.glamenv-septzen.net/view/1071

Maven独自のソースツリーと、Eclipse上でJava保存→即時コンパイル→コンテキストリロード、そこまでは何かしら解決策があります。どうしてもMavenのjarファイル依存関係、それがボトルネックになり、jetty:runかdeployして実行（場合によってはリモートデバッグ接続）かの分水嶺となっています。

2012-04-09 追記
tomcat-maven-plugin を使うことで、JettyだけでなくTomcatでもdeployせずにEclipse上からシームレスにデバッグまで繋げられることが出来ることが判明しました。

以前、WebLogic と Ant でJ2EEサーバの機能を使用したWebアプリを開発していたときは、外部でリモートデバッグ接続を有効にしたWebLogicを立ち上げておいて、そちらにAntからwarをdeploy→Eclipseからリモートデバッグ接続、という手順を踏んでいました。多少のタイムラグはありましたが、それでもリズムを崩す程ではなかったです。
Tomcat7のVirtual webappも「よくぞ対処してくれた」感はあるものの、やはりjarファイル依存関係のスマートな解決策が見当たらないので今ひとつな感じがあります。

他、参考：

• Maven war plugin Introduction
  • http://maven.apache.org/plugins/maven-war-plugin/
• How do I run a maven web application in Tomcat from Eclipse? - Web Tutorials - avajava.com
  • http://www.avajava.com/tutorials/lessons/how-do-i-run-a-maven-web-application-in-tomcat-from-eclipse.html

• [ Prev ]
• [ Next ]
• [ Java ]

Apache Maven メモ (Maven2系)

• 本家
  • http://maven.apache.org/index.html
• Maven-TECHSCORE- (日本語)
  • http://www.techscore.com/tech/ApacheJakarta/Maven/

以下、本家やTECHSCOREを見比べつつ自分用メモ

ドキュメントが沢山有りすぎてどこから手をつけて良いか分からない

1. とりあえずTECHSCOREに目を通す。
2. 本家の見方
   1. ダウンロードとインストール： http://maven.apache.org/download.html
   2. maven-archetype-quickstart でMavenを動かしてみる： "Documentation" > "User Centre" > "Maven in 5 Minutes"
      1. http://maven.apache.org/guides/getting-started/maven-in-five-minutes.html
   3. 「○○したいけどどうすればいいの？」その１ : "Documentation" > "User Centre" > "Getting Starged Guide"
      1. http://maven.apache.org/guides/getting-started/index.html
   4. 「○○したいけどどうすればいいの？」その２ : "About Maven" > "FAQ(official)"
      1. http://maven.apache.org/general.html

Maven提供のpluginのバージョンを調べたい

例えば maven-compiler-plugin でコンパイラオプションを指定したい場合、以下のpluginエントリを追加するわけですが・・・

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-compiler-plugin</artifactId>
  <version>?.?.?</version>
  <configuration>
    ...
  </configuration>
</plugin>

自分が使っているMavenでの"version"はどうやって調べればよいのか？

→ "help" plugin の "effective-pom" ゴールを実行し、デフォルト設定を確認する。

> mvn help:effective-pom
...
        <plugin>
         <artifactId>maven-compiler-plugin</artifactId>
         <version>2.0.2</version>
       </plugin>

"Available Plugins"("Documentation" > "Maven Plugins"), http://maven.apache.org/plugins/index.html に載っているバージョンだと最新のバージョンになってしまいます。とりあえず自分が今使っているMaven提供pluginのバージョンを調べたい時は、effective-pom経由の方が正確だと思います。

依存ライブラリのgroupId/artifactId/version情報を正確に調べたい

• TECHSCOREの "3.1.2. groupId, artifactId, version に指定する値の調べ方"
  • http://www.techscore.com/tech/ApacheJakarta/Maven/3.html

↑だけで見つからない場合は、Maven FAQ(official) に紹介されているその他の検索サイトを使ってみましょう。

• How to find dependencies on public Maven repositories?
  • http://maven.apache.org/general.html#How_to_find_dependencies

但し検索サイトによってはバージョンが古かったりしますので、複数試してみることをオススメします。

個人的には次の二つが好みです。
http://mvnrepository.com/ : 依存・非依存artifactsやlicense情報を表示してくれる。
http://mavensearch.net/ : repository情報も表示してくれる。

• [ Prev ]
• [ Next ]
• [ Up ]
• [ Java ]

Eclipseプロジェクトフォルダの直下に .git がある場合はちゃんとアイコンオーバーレイも表示されるしプロジェクトアイコン右クリックのチーム("Team")メニューにEGitの用意してくれたサブメニューがちゃんと表示されて利用できる。

some_prj/
    .classpath
    .project
    .git/
    src/
    bin/
    ...

↑は問題なし。

ところが、複数Prjが.gitのある階層の下に並ぶと、EGitからインポートしてもアイコンオーバーレイ表示されないしプロジェクトアイコン右クリックしてもTeamにEGitが出てこない・・・。

some_projects/
    .git/
    prj1/
        .classpath, .project, src/, bin/, ...
    prj2/
        .classpath, .project, src/, bin/, ...

↑これでハマった・・・。

ちょこっとだけggrksしてみたらStackOverflowとかにも何やら似たようなトラブルが載っているっぽい・・・。まぁ、特にgitのデータベースが壊れるとかそういった現象ではない。単純に、Eclipseプロジェクトフォルダより上位階層までは .git/ の存在を確認してないだけかもしれない。なので、最悪、git操作はターミナル等のCUIからおこなっても問題ない。

ちなみに、MercurialEclipseではちゃんと上位の .hg/ ディレクトリを認識してくれました。

• [ Prev ]
• [ Next ]
• [ 技術 ]

MacOSX (Lion, 10.7) 以降でのプログラミング向けテキストエディタ環境検討メモ。
「Software Design 2011年12月号」で紹介されていたのも参考。
独断と偏見で、Windowsで著名なエディタで言うとどれにあたるか、という基準でコメントしてます。

• CotEditor プロジェクト日本語トップページ - SourceForge.JP
  • http://sourceforge.jp/projects/coteditor/
    • Windowsで言うところのTeraPadに近い。カラーリングは自分で定義できる。
    • vimのシンタックス定義をCotEditor用に変換：踊るサボテン工房｜Mac｜CotEditor のシンタックス定義
      • http://odorusaboten.web.fc2.com/mac/coteditor_syntaxs.html
• mi - テキストエディタ
  • http://www.mimikaki.net/
    • 複数ウインドウのタブ化や、「モード」ごとにシンタックスハイライトだけでなくフォントや強調表示などかなりの設定項目を切り替えられる点から、Windowsで言うところのsakuraエディタに近いと思われる。
• macvim-kaoriya - MacVim KaoriYa - Google Project Hosting
  • http://code.google.com/p/macvim-kaoriya/
    • MacVim + 香り屋さんのパッチで、WindowsのgVimと同等の使い勝手となっている。ぶっちゃけMacではCUIのvimがデフォルトで入っているので、わざわざgVimを導入する必要性は無いと言えば無いのだが、vimユーザとしてはあればそれなりに、というか非常に便利。

• [ Prev ]
• [ Next ]
• [ 技術 ]

1.45まで：

$ jar -tf bcprov-jdk14-1.45.jar | grep X509V3CertificateGenerator
org/bouncycastle/jce/X509V3CertificateGenerator.class
org/bouncycastle/x509/X509V3CertificateGenerator.class

org.bouncycastle.jce.X509V3CertificateGeneratorが存在している。

1.46になり：

$ jar -tf bcprov-jdk14-146.jar | grep X509V3CertificateGenerator
org/bouncycastle/x509/X509V3CertificateGenerator.class

org.bouncycastle.jce.X509V3CertificateGeneratorが無くなっていた・・・。何故に？

日記/2012/03/10/Eclipse3.7(Indigo)でMavenとSubversion環境セットアップメモ ではEclipseにMavenプラグインを導入し、既存のEclipse用Mavenプロジェクトをインポートするところまでを解説しました。
今回は、素のMavenプロジェクトをEclipseのプロジェクトに取り込む方法をメモ。ここで言う「素のMavenプロジェクト」というのは、".project"や".classpath"ファイル, ".settings"ディレクトリなどが作成されていない、Eclipseプロジェクトとは認識されないファイルセットを指します。
ということで、今回は myart3 という以下の構造のMavenプロジェクトを「Eclipse化」してみます。

/work/tmp/mvntest/myart3/
    pom.xml
    src/main/java/foo/bar/App.java
    src/test/java/foo/bar/AppTest.java

※今回は "Maven Eclipse Plugin" ( http://maven.apache.org/plugins/maven-eclipse-plugin/ ) は取り上げません。また、マルチモジュール化されたMavenプロジェクトの取り込みについてはまたの機会に。

1. SCMに登録してない素のMavenプロジェクトをEclipse化する

まずEclipseのインポートメニューからMavenの "Existing Maven Projects" を選択します。

続いてpom.xmlのあるディレクトリを"Root Directory"として選択すると、自動的にインポートするプロジェクトがリストアップされます。

インポートに完了後、Eclipseのナビゲータビューで確認すると".project", ".classpath", ".settings" が作成されています。

プロジェクトのプロパティから場所を確認：

".classpath"を覗いてみると、m2e専用のコンテナが設定されていることを確認できます：

$ cat .classpath 
<?xml version="1.0" encoding="UTF-8"?>
<classpath>
	<classpathentry kind="src" output="target/classes" path="src/main/java"/>
	<classpathentry kind="src" output="target/test-classes" path="src/test/java"/>
	<classpathentry kind="con" 
path="org.eclipse.jdt.launching.JRE_CONTAINER/org.eclipse.jdt.internal.debug.ui.launcher.StandardVMType/J2SE-1.5"/>
	<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER"/>
                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
	<classpathentry kind="output" path="target/classes"/>
</classpath>

2. SCM上から素のMavenプロジェクトをインポート("Check out Maven Projects from SCM"版)

SCM上に素のMavenプロジェクトが登録されている状態で、それをチェックアウト。
今回はローカルのSubversionリポジトリで以下を用意し、その直下にmyart3をコミットしています。

file:///work/SVNREPOS/test1

まずはインポートメニューからMavenの"Check out Maven Projects from SCM"を選択します。ちなみにこのメニューは、すでにEclipseプロジェクト化されたMavenプロジェクトをSCMからチェックアウトする場合も利用できます。
SCM URLでSubversionのローカルリポジトリを指定しています：

locationなどカスタマイズできます。何も入力しないデフォルトのままインポートすると、Eclipseのナビゲーションビューで以下のように".project"などのファイル・ディレクトリが作成されたことが確認されました。

一方で、以下のように"maven"で始まる適当なディレクトリにチェックアウトされてしまいましたので注意が必要です。

3. SCM上から素のMavenプロジェクトをインポート("Existing Maven Projects"版)

予めsvnコマンドやTortoiseSVN等でローカルにチェックアウトしておきます。
今回は以下のディレクトリにチェックアウトしました：

$ pwd
/work/tmp/mvntest/test1/myart3
$ svn info
Path: .
URL: file:///work/SVNREPOS/test1/myart3
Repository Root: file:///work/SVNREPOS/test1
...

EclipseのインポートメニューからMavenの "Existing Maven Projects" を選択し、チェックアウトした素のMavenプロジェクトのディレクトリを "Root Directory" に設定します。以降は 1. の時と同じです。
EclipseのSubversiveプラグインの方で ".svn" を認識してくれますので、 "2." と同様にSubversionの機能も利用できます。

この手順であれば、"2."のような"maven...."の中にチェックアウトされるようなことも無いので、こちらを個人的にはお勧めします。

MarketPlaceからのインストールなど、ビミョーに変わってたりするのでメモ。

1. Eclipse 3.7 (Indigo) Java開発用をGET

MergeDocのPleiadesを使ってもいいし、eclipse.orgからGETしても良い。

• MergeDocのPleiades, "Ultimate"か"Java"を使います。
  • http://mergedoc.sourceforge.jp/
• eclipse.orgからのDL : 特にこだわりが無ければ"Eclipse IDE for Java EE Developers"で良いと思います。
  • http://www.eclipse.org/downloads/

2. Subversiveをインストール

Eclipse上でSubversionのリポジトリからチェックアウトしたりcommit出来るようになります。
MergeDocのPleiadesの場合、既にsubversiveが同梱されてますのでskipです。

eclipse.orgからDLした場合：

1. "Help" -> "Eclipse MarketPlace" -> "subversive"で検索
2. "Subversive - SVN Team Provider" をインストール
3. インストールしてEclipseを再起動すると、コネクタ選択画面が出てくる(出てこない場合は適当にSVNリポジトリからチェックアウトしようとすると初回に訊かれるハズ)ので、SVN Kitなり適当なコネクタ（ドライバ？）を選択。

3. m2e をインストール

Eclipse上でMavenプロジェクトを作成したり、"mvn"コマンドのランチャーからビルドしたり出来るようになります。また、Eclipseプロジェクト用にビルドパスを調整してくれます。

Eclipse 3.6(Helios)の頃は"m2eclipse"だったんですが、3.7(Indigo)時代では単に"m2e"と呼ばれているようです。ヤヤコシイですね。

1. "Help" -> "Eclipse MarketPlace" -> "m2e"で検索
2. "Maven Integration for Eclipse" をインストール

4. m2e-subversiveをインストール

さて、これでSubversionとMavenそれぞれの環境は整いました。
ところが、これだけでは "SVN上のMavenプロジェクトをインポートする" というのが出来ません。
インポートメニューから "Check out Maven Projects from SCM" を選択しても、以下のようなダイアログになり適切なSCMを選択できません(SCMのプルダウンメニューが空っぽ)。つまり、まだMavenプラグインとSCMとの連携が取れていない状況です。

そこで、上図の右下、"Find more SCM connectors in the m2e Marketplace" をクリック。
これでようやく、m2e用のsubversiveコネクタが一覧の下の方に出てくるので、インストール。

→

これで無事、"Check out Maven Projects from SCM" のダイアログで "svn" をSCMとして選択できるようになりました。

5. 動作確認

動作確認用のサンプルとして、昔作成したTCP/IPの"Echo"サーバをMaven + Eclipseプロジェクト化してcodereposに上げてありますので、これで連携を確認してみます。

1. "Check out Maven Projects from SCM" で次のSVN URLを指定
   1. http://svn.coderepos.org/share/lang/java/echo_samples/act9
2. 適当にworkspaceにチェックアウトでき、パッケージエクスプローラ上のプロジェクトアイコンで、左上に"m"のマーク、右下にSubversiveのマークが表示されるまでwktkして待つ。
3. Elipseが落ち着いたら、プロジェクトのプロパティ右クリック -> "Run as" -> "Maven build" で、goalsに"package"を設定して実行。
   1. 
   2. 
4. プロジェクトのプロパティからビルドパスを確認すると、それなりにjarファイルを参照してます。
   1. 
   2. これら全部をいちいちDLして登録するのが面倒くさい！という場合にMavenは効果的です。もちろん、CUIからビルドできるので作業の自動化と相性が良いというのもあります。

6. 参考資料

個人のBlog記事を参考にする場合は、必ず使っているEclipseのバージョンを確認してからにしてください。
特にm2eclipse関連では、2009年～2010年頃までの記事はほぼ全て、Eclipse 3.7 Indigo では参考にならないと考えて良いです。たった数年、数回のアップデートで、プラグインの名前やインストール方法が変わっています。昔の記事を参考に、昔のやり方でインストールするのは地雷原に何の準備もせず突っ込むような所業です。

2012-03時点(Eclipse 3.7時代)では、sonatypeの資料が一番オススメです。

• Books / Support Sonatype.com
  • http://www.sonatype.com/Support/Books

しかしこれですらEclipse用の資料は3.6(Helios)時代であり、3.7では下記の差異がありましたので注意が必要です。

1. プラグイン名が"m2eclipse" -> "m2e"
2. MavenとSubversionの連携で、MarketPlaceでは "Maven Integration for Eclipse (Extras)" を探しても見つからず、"Check out Maven Projects from SCM"の"Find more SCM connectors in the m2e Marketplace"からインストールする必要があった。

MavenとEclipseの連携はこのようにめまぐるしく変化していますが、Maven単体では利用者視点ではそれほど大きな変化はありません。
現在のメジャーバージョンはMaven3ですが、Maven2時代のテクニックはほぼ通用します。実際本記事で動作確認に使っている"echo_samples/act9"もMaven2時代に作成しています。
ただ、正直 Apache のMavenサイトのドキュメントは構成が分かりやすいとは言いづらいものがあり（個人的な感覚差はあると思います）、英語が読める方には上述のsonatypeの資料をお薦めします。
日本語ではTECHSCOREの記事がオススメでしょうか。

• Maven | TECHSCORE(テックスコア)
  • http://www.techscore.com/tech/Java/ApacheJakarta/Maven/index/

また、本記事では取り扱っていませんがMaven単体で作成したプロジェクトをEclipseに取り込むなどの作業については別途ノウハウが必要ですので、適宜調べてみてください。

Maven3, Jetty8, Eclipse 3.7(Indigo), m2eclipse 前提

mvn archetype:generate

で、org.codehaus.mojo.archetype:webapp-xxyy でプロジェクト作成。バージョンは適当に選ぶ。今回はwebapp-jee5を選択。

340: remote -> org.codehaus.mojo.archetypes:webapp-j2ee13 (-)
341: remote -> org.codehaus.mojo.archetypes:webapp-j2ee14 (-)
342: remote -> org.codehaus.mojo.archetypes:webapp-javaee6 (-)
343: remote -> org.codehaus.mojo.archetypes:webapp-jee5 (-)

codehausのarchetypeを選択するメリットとしては、src/main/java 以下のパッケージまでが展開されること。org.apache.maven.archetypes:maven-archetype-webappだと src/main/webapp/ までしか作ってくれない。

このあとEclipseで既存のMavenプロジェクトとしてインポートし、適当にServletクラス作成して、web.xmlに適当に登録する。
プロジェクト右クリックで Maven Build みたいなのを選択し、ゴールに "package" を指定して実行すれば target/ の下にwarファイルが作成される。

これを実行するためにTomcatを使うという手法もあるが、今回はJettyを使ってみる。

• Jetty6まで : maven-jetty-plugin
  • http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin
• Jetty7以降 : jetty-maven-plugin
  • http://wiki.eclipse.org/Jetty/Feature/Jetty_Maven_Plugin

pom.xmlに上記ドキュメントに指定されたとおりに jetty-maven-plugin を追加し、EclipseでMavenの "jetty:run" ゴールを指定してデバッグ実行する。
ただこれだけだとソースコードが対応付けられていない。Debugパースペクティブを開きJettyのプロセスを右クリック→ "Edit Source Lookup" ソース探索パスを追加する。プロジェクト単位で追加できるし、Workspaceでごっそりと追加することも可能。
これでブレークポイントなどがソースコードと連携し、デバッグしやすくなる。

Maven + Jettyの何がよいかというと、test系と相性が良くなるようなきめ細かい設定が可能となっている。上述のドキュメントでは 「jetty:start : Starting jetty without first executing the build up to "test-compile" phase」のセクションで integration-test の前後で自動的にJettyを起動・停止するような設定例が書かれている。
またTomcat系の独立したWebApplicationServerと異なりwarファイルのデプロイ、それにともなうサーバのセットアップや設定の調整が不要な点も評価できる。

参考：Maven + Tomcatの例

• 5. Maven による実アプリケーション開発 | TECHSCORE(テックスコア)
  • http://www.techscore.com/tech/Java/ApacheJakarta/Maven/5/