Mavenのビルドですが、公式ドキュメントどおりでうまくいきます。ちなみに、Debian上です。
ただし、CVSからソースを新規にダウンロードしました。ソースのツリーが変わったのか、既存の環境にcvs updateするとゴミが残ってコンパイルを邪魔するので（cvs update -d -Pとしても効果なし）、新規にcvs checkoutしました。
Mavenでビルドできるプロジェクトなら、とりあえず$ maven -gして、どんなコマンドが有効なのか確認します（Antの$ ant -projecthelpに相当）。一番大きなくくりは、たぶん$ maven site:generateです。Antとは違って、引数にはname spaceがあります。これで、各種情報を含んだWebページができあがります。$ maven dist:buildも大きなくくりです。
その他には、$ maven java:jarで、クラスファイルができあがります。$ maven javadoc:generateで、JavaDocが生成されます。生成されるものは全てtargetディレクトリに置かれます。Antでいう、buildやdistディレクトリです。
このような処理はAnt同様、プラグインで実装されています。多数のプラグインがデフォルトで組み込まれています。Mavenのプラグインが想定する機能は、Antよりも広い概念です。すなわち、「ファイルをコピーせよ」とかではなくて、上記のsite:generateのように「プロジェクトのWebサイトを作れ」のようなものです。
Mavenの凄い点は、Webサイトを作るための特別な設定が必要ないことです。ここがAntと決定的に違う点です。project.xmlに、開発者の名前や依存Jarファイルといったプロジェクトの情報を書き、決められたパスにソースやテストソースを置いておけば（変更もできる）、site:generateでデフォルトのWebサイトができあがります。コンパイル、JavaDoc、アーカイブなど、まさにMavenのサイトそのもののようなWeb一式です。Webサイトのための特別な設定は、デフォルトのままでよいなら、必要ないのです。
project.xmlは、Antのbuild.xmlとは違います。build.xmlはコマンドの定義ですが、project.xmlはプロジェクトの情報です。プラグインで定められたデフォルト動作のままでよいなら、コマンドを定義する必要がMavenにはありません。もちろんコマンドも定義できて、それはmaven.xmlに書きます。これがAntのbuild.xmlに相当します。繰り返しますが、maven.xmlがなくても、とりあえず動作します。
prject.xmlの書き方は、既存のもの（例えばMaven自身のもの）を修正すればこと足りるでしょう。見えにくいのが、デフォルトでファイルをどこに置くかと、maven.xmlをどう書くかです。
具体的にプロジェクトを自分で作るときに悩ましいのが、依存するJarの置き場です。Jakartaものなどpublicなものはネット上のJarアーカイブにたいていあるのでそのままproject.xmlに設定して問題ないのですが（でも最新バージョンがないこともある）、問題は、自分で作ったJarを参照するときです。この置き場（Antでいうlib）を定義することができないので、Jarがダウンロードされるリポジトリに自分のJarも置き、ダウンロードされたように見せかけます。ここがかなり面倒です。だから、リポジトリを、Mavenに1つ共有ではなく、プロジェクトごとに設定するのがよいようです。でもこれだとなんか、もともとの理念に反するようで、腑に落ちないのですが。
XMLにはいろいろな用途がありますが、例えばAntのbuild.xmlは、シェルスクリプトのようなものと考えることができます。コマンドに対応する実装はJavaでタスクを書き、プラグインすることができます。XMLはスクリプトファイルだというこのような発想を体現しているのが、Apache Jellyです。そのJellyの上に構築されているのがMavenです。今後、いろいろなプロジェクトが、Jellyに統一されていくかもしれません。同じものを2つ開発していく必要はないのですから。
以上、書き始めたら止まりませんでした。ちょっと古い知識なので、優れた機能がMavenに導入されていたらツッコミください。他人任せでなく、自分でMavenレポートのひとつでも真剣に書くべきなのですが。なお、10人ツッコミもらえても書けません。AspectJ調べたいし。
つまり、プロジェクトを開発する観点からはAntが便利です。細かいスクリプトを書いていけますから。逆ですね、プロジェクトに必要なスクリプトをいろいろ書いていく必要に迫られます。しかも、同じような処理でも、プロジェクトごとに微妙に違ったりします。一方、プロジェクトのリリースを管理するにはMavenが便利です。特に、publicなプロジェクトには便利でしょう。私は最初開発が楽になるのかと思ってMavenを触ったのですが、以上のようにその点はそうとも限らないのです（便利な点ももちろんあるが）。だから、Jakartaの開発者がMavenを欲する気持ちはよく分かるのですが、一般のプログラマが使ってとても便利かというとちょっと疑問です。Antで十分でしょう。オープンソースなプロジェクトにははやるでしょうが、一般にははやらないかもしれません。
もうちょっと正確に言うと、AntでできることはMavenにもできるので（Mavenのコマンドで書いてもよいし、それこそMavenからAntを呼び出してもよい）、MavenはAntを含ます。しかし、AntでできることをMavenでやらずとも（特に、Mavenの情報が少なくMavenが不安定な今）いいわけです。Mavenでしかできないことは、開発という視点を超えるものが多いので、別物と捉えたほうがよいのかも知れません。
Mavenは、Linuxでいうパッケージ化の技術かもしれません。基本はmake（ant）でコンパイルするのですが、それをディストリビューションに合わせたパッケージにするにはaptなりrpmなりが必要です。ディレクトリ構造が厳格に決められているDebian aptが便利なように、Javaプロジェクトの標準にMavenがなるかもしれません。そのときでも、開発者がコンパイルにつかうのはAntでしょう。
うーん、WARやEARの作成はMavenで便利になるでしょうし、AntとMavenの関係は同じような違うような、微妙です。