Mavenは今より良いのGradleを作るがあるが、この機能を使用することからHaoshi [について]、優れたプロジェクト管理ツールを作成するには、プロジェクトに反映させることができるJavaの世界ですが、Mavenの状況はそうではありません簡単にサポーターの多くは、まだ、振とうします。
Mavenのの背景
新しい知識を学ぶ前に、新たな技術の原因を見て歴史的な視点だけでなく、バックグラウンドで技術的な問題、ので、この技術をよりよく理解する必要があります。
必要性は基本的にこのように、誰か他の人の時間によって書かれたコードを使用するMavenの、プロジェクトの開発が存在しない場合には：
1.他の人が書かれたjarファイルのパッケージを使用する必要がある場合、あなたはJava実行環境を伝えるために、このディレクトリに応じてプロジェクトにオープンソースのjarパッケージのlibディレクトリをダウンロードする必要がある、とCLASSPATHに追加したプロジェクトの開発ここでディレクトリが必要に実行されるクラスまたはパッケージのJavaプログラムを見つけることができます。
ダウンロードaa.jarはbb.jarパッケージを依存しているので、ダウンロードbb.jarパケットを移動し、ダウンロードが必要なすべてのjarファイルのパッケージを追加されるまでの工程を繰り返すも見パッケージ2の後。
3.あなたが追加した後、すべてのプロジェクトの依存関係が正常動作することができ、幸運なら。しかし、不運場合、バージョンは、このようなパッケージは、彼らがbb.jarパッケージを呼び出すときに、この方法が唯一の別のパッケージbb.jarに存在し、必要はありませんでしたbb.jar aa.jarパッケージ発見方法などの問題に遭遇しますバージョンは、このような場合は、我々はジャーパッケージの外観に依存して適応したバージョンに多くの時間を費やす必要があります。
4.また、gitのやsvnにコードを提出する時には、また、そうでない場合、私はあなたを見つけると追加に依存するために行われている全ての前で繰り返します、これらすべてのLIBは、最大アップロード配置する必要があります。同様に、他の人があなたの完全なコードもlibがダウンロードしなければならないダウンロードしてください。このように、タイムコードのバージョン管理、コード空間のバージョン管理の無駄、だけでなく、開発時間のコストが増大し、開発の効率を低下させます。
世界でのMaven Javaのパッケージ管理ツールとして、この時間はされて入ってきました。ただ、Linuxの世界のようにyumを、Webフロントエンドの世界のWebPACKとして、それはさまざまな依存関係のパッケージ管理ツールを管理するために便利で、開発者です。
種類Mavenのリポジトリ
デフォルトは中央リポジトリである（見つけられない、あなたは中央の倉庫に行き、それを見つけることができない、PW（もしあれば設定さPW）を探しに行く。最初のローカル倉庫を見つける：プロセスのMavenのjarファイルのパッケージがこれです検索http://repo1.maven.org/maven2/で、Mavenのチームは）維持する責任があります。
最後に、中央リポジトリが発見された後、PW、地元倉庫が地元の倉庫内の場所、あなたがダウンロードして中央リポジトリに頼る必要はありません見つけるので、次の時間を見つけるPW後から入れた場合。
インストール倉庫の設定、（通常はWindows上で展開し、設定環境変数）まあMavenの、Mavenのインストールディレクトリ後のsettings.xml設定ファイルがあるでしょう、このプロファイルは、confディレクトリに設定の多くを提供します、そのローカル倉庫、アーティスト、中央倉庫を含む構成項目アイテム倉庫があります。
まずPW、PW、より複雑な上に構築するためにすべての、私たちは地元の倉庫と中央倉庫の設定を参照してください、PWの設定をスキップするので、ここでは、記録するために追加のスペースが必要です。
ローカルリポジトリの構成はlocalRepositoryタグによって構成されています。
<！ - localRepository | ローカルリポジトリの達人への道は、成果物を保管するために使用します。 | | デフォルト：$ {のuser.home} / 2 /リポジトリ - > < localRepository > D：\ maven_repo </ localRepository >
中央倉庫構成は、ミラー・ミラー・ラベルによって（淘宝画像にここで設定）が設定されています。
< ミラー> <！ - ミラー | 代わりに与えられたリポジトリを使用するためのリポジトリのミラーサイトを指定します。リポジトリのこと | このミラーは、このミラーのmirrorOf要素と一致するIDを有する機能します。IDが使用されています | 継承と直接参照の目的のために、と鏡のセットで一意である必要があります。 | <ミラー> <ID> mirrorId </ ID> <mirrorOf>リポジトリID </ mirrorOf> このミラーは、<名前>人間が読み取り可能な名前。</名前> <URL> http://my.repository.com/repo/path < / URL> </ミラー> - > < ミラー> < ID >> < mirrorOf >中央</ mirrorOf > < 名前>ネクサスaliyun </ 名前> < URL > http://maven.aliyun.com/nexus/content/groups/public </ URL > </ ミラー> </ ミラー>
これらの設定項目は、そうするように構成されていない場合は、Mavenのは、デフォルト値が供給され、デフォルト値が設定項目ではコメントアウトされていることに留意すべきです。
この点を属性独自の設定では、Mavenは[設定より規約]コンセプト、本当に良いああを実装しています。
Mavenプロジェクトの全体的な構造
Mavenの原則が守られている] [設定より規約ので、デフォルトの設定のMavenプロジェクトでは、この図に構築されています。
デフォルトの設定$ {project.basedir} / srcに/メイン1.Maven / Javaのプロジェクトのソースコードのディレクトリ。
2.Mavenデフォルト設定$ {project.basedir} / SRC /メイン /テストテストコードディレクトリのアイテム。
デフォルトの設定$ {project.basedir} /ターゲットコンパイラの出力ディレクトリプロジェクト3.Maven。
...
それはデフォルトの設定ですので、もちろん、もちろん、修正することができ、プロジェクトをビルドするのpom.xmlにソースコードディレクトリのタグを変更することができますが、一般的に変更することは推奨されていない、ほとんどの人は変更するつもりはありません。
< ビルド> < sourceDirectory >のsrc / javaの</ sourceDirectory > < testSourceDirectory >のsrc /テスト</ testSourceDirectory > < OUTPUTDIRECTORY >出力/クラス</ OUTPUTDIRECTORY > < testOutputDirectory >出力/テスト・クラス</ testOutputDirectory > < ディレクトリ>ターゲット/瓶</ ディレクトリ> </ 構築>
具体Mavenプロジェクトの構造を決定する[設定より規約]特性によって決定されるアリの主前身の一つを無効にするように、この機能は、不要な構成の数を減少させます。
ディレクトリ構造Mavenの管理ツール
以下は、ディレクトリ構造Mavenの管理ツールです。
binディレクトリには：このディレクトリには、Javaコマンド、CLASSPATHへの準備と関連するJavaシステムプロパティを設定して、Javaコマンドを実行するMVN実行されるスクリプトが含まれています。
bootディレクトリ：このディレクトリは、ファイルが叢-classworlds-2.5.2.jarで、一つだけのファイルが含まれています。叢-classworlds設定を容易にするために、より豊かな構文を提供するデフォルトのJavaクラスローダへの相対クラスローダフレーム、で、Mavenは自分のライブラリをロードするためのフレームワークを使用しています。
confディレクトリ：このディレクトリには、非常に重要なドキュメントのsettings.xmlが含まれています。直接ファイルを変更するには、すべてのユーザーに影響を要する機械、上でグローバルにMavenの動作をカスタマイズすることができます。一般的に、我々は次の〜/ .m2 /ディレクトリにファイルをコピーすることを好む、その後のMavenの動作をカスタマイズするために、ユーザレベルでのファイルを変更します。
LIB：ユーザーは、このようなMavenのコア-3.0.jarとして見ることができるように、このディレクトリには、サブモジュールのMaven自体が開発され、必要なすべてのMavenのランタイムJavaクラス・ライブラリが含まれ、maven-モデル-3.0.jar そのような文書ほかにもいくつかのサードパーティは、Mavenのは、コモンズ-CLI-1.2.jar、commons-として使用頼っ含まれているのlang-2.6.jar のような。
settings.xmlの設定ファイル
这里详细说一下settings.xml这个文件，这个文件用于定制Maven的行为。上面已经说到settings.xml可以放在2个位置，一个是【~/.m2/setting.xml】（默认没有，需要我们自己复制），一个是【${maven.home}/conf/setting.xml】。这2个位置的配置文件的加载顺序为【~/.m2/setting.xml】>【${maven.home}/conf/setting.xml】，为了不影响他人，所以我们将conf下的settings.xml复制到用户目录，在用户级别定制Maven的行为。
这个和系统配置环境变量有点类似，Windos和Linux都可以配置系统级别的环境变量和用户级别的环境变量，用户级别的环境变量会覆盖系统级别的环境变量。
Maven的一些常用命令
要使用Maven当然要会一些常用的命令，不然都不叫会使用Maven。
| 命令 | 描述 |
|---|---|
| mvn -version | 显示版本信息 |
| mvn clean | 删除target目录 |
| mvn compile | 编译src/main/java下的源代码 |
| mvn package | 打包，在target下生成jar包或者war包 |
| mvn test | 执行src/test/java下以Test开头或者以Test结尾的类的测试用例 |
| mvn install | 打包，并把jar包或者war包复制到本地仓库，供其他模块使用 |
| mvn deploy | 将打包的文件发布到私服 |
| mvn dependency:tree | 打印出项目的整个依赖树 |
当然也可以将命令连着使用，比如使用【mvn clean package】清理打包；比如使用【mvn clean package -DskipTests=true】清理打包，并跳过测试用例；比如使用【mvn clean install】清理打包，并将jar包或者war包复制到本地仓库。
更多的，也可以配合将结果输出到文件来方便查看，比如【mvn dependency:tree > dependency.txt】。
pom.xml中的<dependency>标签
<dependency>标签中一般是包含<groupId>、<artifactId>和<version>三个子标签。
<groupId>表示公司域名倒过来，<artifactId>表示功能的命名，<version>表示版本号，这三个维度就确定了一个jar包，就像用(x, y, z)坐标在三维空间中确定一个唯一的点一样。
另外的，<dependency>标签中还可以包含<scope>标签，表示此依赖包的作用范围，下面列出一个<scope>参数候选值的表格。
| 参数 | 解释 | 是否会被打入最终的jar包 |
|---|---|---|
| compile | 默认的scope（不指定） | 是 |
| test | 测试使用 | 否 |
| provided | 编译需要 | 否 |
| runtime | 编译不需要，运行时需要（接口与实现分离） | 是 |
| system | 加载本地jar（很少使用） | 否 |
"长得丑的水果，都会努力让自己甜一点。"