独自のパブリックなリポジトリを作成する
Mavenのセントラルリポジトリ以外のリポジトリに依存するプロジェクトの場合は、独自のパブリックなリポジトリを作成することを検討しましょう。このためには、パブリックのWebサーバーと、そのWebサーバーのファイルシステムにファイルをデプロイするためのメカニズム（FTPサーバーなど）、そしてPOMの若干の変更が必要です。最適なトランスポートメカニズムのインストールとセットアップ方法を説明したWeb関係の記事はたくさんありますが、この例ではWebDAVを使ってプロジェクトのアップロードを受け入れています。サーバーを構成したら、すべてのプロジェクトの継承元となる親POMを作成します。これで、デプロイメントはかなり楽になります。親POMに次のブロックを追加します。
<project> <artifactId>my-parent</artifactId> ... <build> <extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-webdav</artifactId> <version>1.0-beta-1</version> </extension> </extensions> </build> <distributionManagement> <repository> <id>codehaus-mojo</id> <name>Repository Name</name> <url>dav:https://dav.codehaus.org/repository/mojo/</url> </repository> </distributionManagement> </project>
URLのプレフィクスには、サポートされているWagonプロバイダのいずれか、つまりMavenが正しいリポジトリにファイルをトランスポートする場合に使うメカニズムを指定します（サポートされているプロバイダの種類については、ここをクリックしてください）。プロバイダの指定に加えて、使用するトランスポートメカニズムに対応するビルド拡張も追加する必要があります。この場合はWebDAVなので、wagon-webdavを追加しました。
このサーバーにビルドをデプロイすることができるユーザーを制御するには、中心となる開発者にユーザー名を割り当てます。各ユーザーは、Mavenのインストール構成ディレクトリまたはローカルリポジトリディレクトリ下にある各自の「settings.xml」ファイルに、対応するリポジトリIDを指定することができます。
<settings> ... <servers> <server> <id>codehaus-mojo</id> <username>joe</username> <password>c4ntGuessThi5</password> </server> </servers> ... </settings>
このように開発者のローカル設定に変更を加える必要はありますが、ポータビリティには影響しません。心配な点は、クライアントビルダがローカルで変更を行わずにビルドとインストールを実行できるかどうかだけです。これは、彼らのためにリポジトリへのデプロイを簡単にする必要がある、という意味ではありません。
他のデプロイ済みのプロジェクトに依存するプロジェクトについては、次のようにrepository要素を介して、リポジトリのパブリックな性質を追加することができます（Apache HTTP ServerなどのシンプルなWebサーバーを用いてパブリックにします）。
<project> ... <repositories> <repository> <id>codehaus-mojo</id> <url>http://repository.codehaus.org/org/codehaus/mojo/</url> </repository> </repositories> </project>
これでプロジェクトのポータビリティはワイドになりました。単なるインハウスのポータビリティにしたい場合は、ネットワークアクセスを制限して、リポジトリを利用するための「会員制クラブ」を設けます（必要なのは、秘密のハンドシェークだけです）。
市販のライセンス付きリモートリポジトリをインハウス化する
ライセンス問題のためにプロジェクトをポータブルにできず、チームが成果物を手動でダウンロードしてインストールせざるを得ないこともあります。通常ならこれによってプロジェクトは非ポータブルの穴に落ちてしまいますが、Mavenではこの問題を単なる小さな頭痛の種程度に抑えています。例えば、「sometool.jar」というクローズドソースのJARのライセンスを持っているとします。これを次のようにインハウスのリポジトリ内にインストールすることで、他のMavenの成果物とまったく同じように他の社員もそのJARにアクセスできるようになります。
mvn deploy:deploy-file -DgroupId=com.closedsource -DartifactId=sometool-Dversion=1.0 -Dpackaging=jar -Dfile=sometool.jar -DgeneratePom=true
-Dversion=1.0 -Dpackaging=jar -Dfile=sometool.jar -DgeneratePom=trueこれで、非ポータブルなプロジェクトが、ライセンス制限を受けてはいますがインハウスのポータビリティを持つプロジェクトになります。
javax.*を取得する
従来のjavax.*パッケージはすべて、ライセンス制約のためにSunのWebサイトから手動で成果物をダウンロードしてインストールする必要がありましたが、もうその必要はありません。java.netで、javax.mail、javax.persistenceなどのいくつかのパッケージを含むパブリックなMaven 1.xリポジトリと2.xリポジトリが作成されました。どちらのリポジトリにも、プロジェクトのPOMに次のブロックを追加することでアクセスできます（Maven 1.xリポジトリのlayout要素に注意してください）。
<repository> <id>java.net</id> <url>https://maven-repository.dev.java.net/nonav/repository</url> <layout>legacy</layout> </repository> <repository> <id>maven2-repository.dev.java.net</id> <name>Java.net Repository for Maven</name> <url>https://maven2-repository.dev.java.net/nonav/repository</url> </repository>
これで、email APIを使用する非ポータブルなプロジェクトを、手動インストールの必要がないワイドなポータビリティを備えたプロジェクトにすることができます。
ポータビリティの夢
Mavenのおかげで、ビルドプロセスそのものの標準化を始めることができるようになりました。完全ではないものの、MavenはJava開発の大きな躍進であり、純粋でシンプルなポータビリティの夢を現実のものにしてくれます。
