pom.xmlおよびsettings.xml
pom.xmlおよびsetting.xmlは、Mavenのコア関数を決定するMavenで最も重要な2つの構成ファイルであると言えます。以前の記事では、POM.xmlの内容と断片のsettings.xmlについて言及しましたが、それらはすべて簡単に言及されており、学習と研究は詳細ではありません。この記事の目的は、これら2つの重要な構成ファイルを詳細に研究することです。これらの2つの構成ファイルは、多くのMavenトピックにつながる可能性があります。
メイブン座標
まず、Maven座標を使用する必要がある理由について話しましょう。
Maven Worldには、非常に多くのコンポーネントがあります。つまり、通常使用されるいくつかの瓶、戦争、その他のファイルがあります。 Mavenがこれらのコンポーネントの座標の概念を導入する前に、これらすべてのコンポーネントを一意に識別する方法を使用することはできません。したがって、Spring依存関係を使用する必要がある場合は、Springの公式Webサイトにアクセスして検索します。 log4j依存関係を使用する必要がある場合は、Apacheの公式Webサイトにアクセスして検索してください。各Webサイトのスタイルが異なるため、Webページの検索と閲覧には多くの時間が費やされています。統一された規範と規則がなければ、作業を自動化することはできず、繰り返し労働を機械に任せる必要があります。
Mavenは一連のルールを定義します。世界の任意のコンポーネントは、Maven座標によって一意に識別できます。 Maven座標要素には、GroupID、ArtifactID、バージョン、パッケージング、および分類器が含まれます。正しい要素座標を提供する限り、Mavenは対応するコンポーネントを見つけることができます。ダウンロードする場所については、Maven自体には、中央の倉庫「http://repo1.maven.org/maven2」の組み込みアドレスがあります。セントラルウェアハウスには、世界で人気のあるオープンソースプロジェクトコンポーネントのほとんどが含まれています。 Mavneは必要に応じてそれらをダウンロードします。もちろん、独自のセントラルウェアハウスアドレスを構成し、独自のセントラルウェアハウスにコンポーネントをダウンロードすることもできます。
たとえば、Springのコンテキスト：
<Dependency> groupId> org.springframework </groupId> <artifactid> spring-context </artifactid> <バージョン> 4.2.6.release </version> </dependency
部下の要素を見てみましょう。
これは、ほぼマベン座標の概念です。 Maven Coordinatesを理解することは、Mavenを理解するための非常に重要なステップです。
推移的依存関係
推移的依存関係とは何ですか？例として春を取ります。 Springを使用する場合、他のオープンソースクラスライブラリに依存します。これを行うには2つの方法があります。
1.すべてのスプリングジャーを含む大きな.zipパッケージをダウンロードしますが、多くの場合、多くの不要な依存関係を紹介することがよくあります
2.スプリング関連の.zipパッケージのみをダウンロードします。依存関係は含まれません。それらを使用する場合、エラー情報に従って必要な他の依存関係を追加します。
明らかに、両方のアプローチは非常に面倒であり、Mavenの推移的依存メカニズムはこの問題をうまく解決します。 Spring-Core-4.1.0.Releaseのpom.xmlを開き、重要な部分を傍受します。
<Dependencies> <Dependency> <groupId> Commons-Codec </groupId> <artifactid> commons-codec </artifactid> <version> 1.9 </version> <scope> compile> compile> compile> optional> </dependency> <septionid> commons <バージョン> 1.1.3 </version> <scope>コンパイル</scope> </dependency> ... </dependencies>
たとえば、プロジェクトAはスプリングコアに依存し、スプリングコアはコモンズコデックとコモンズログに依存するため、コモンズコデックとコモンズログはプロジェクトAの推移的依存関係です。スプリングコアを使用する場合、依存するものを考慮する必要はなく、不必要な依存関係を導入することを心配する必要はありません。 Mavenは、各直接依存POMを解析し、必要な間接依存関係を推移的依存関係の形で現在のプロジェクトに導入します。
一方で、推移的な依存メカニズムにより、依存関係宣言を大幅に簡素化および促進します。一方、ほとんどの場合、プロジェクトの直接的な依存関係が何であるかを気にするだけで、これらの直接的な依存関係によってどのような推移的依存関係が導入されるかを考慮する必要はありません。ただし、推移的な依存関係にもいくつかの問題がある場合があります。この時点で、推移的依存性が導入された経路をクリアする必要があります。これは依存関係の調停と呼ばれます。依存関係の調停には2つの主要な原則があります。
1。a-> b-> c-> x（1.0）、a-> d-> x（2.0）、この時点で、2つの依存関係パスにxの2つのバージョンがあります。現時点では、最も近いパスが推奨されるため、x（2.0）が解析されて使用されます。
2。a-> b-> y（1.0）、a-> c-> y（2.0）、y（1.0）、y（2.0）の依存関係の長さは同じです。 Maven2.0.9から始めて、最初のステートメントは優先順位に従います。つまり、最高順序の依存関係が推奨されます。
依存関係を除外します
推移的依存関係は、プロジェクトに多くの依存関係を暗黙的に導入し、プロジェクトの依存関係の管理を大幅に簡素化することがありますが、この機能も問題を引き起こす可能性があります。たとえば、状況があります。
現在のプロジェクトはAに依存します。Aは、何らかの理由で別のクラスライブラリのスナップショットバージョンに依存します。このスナップショットは、現在のプロジェクトの推移的な依存関係になります。第二に、スナップショットの不安定性は、現在のプロジェクトに直接影響します。現時点では、スナップショットを除外する必要があり、クラスライブラリの正式なリリースバージョンが現在のプロジェクトで宣言されています。
依存関係を除外するのは非常に簡単です。執筆方法を見てみましょう。
<Dependency> GroupId> com.alibaba.rockemmq </groupid> <artifactid> Rocketmq-client </artifactid> <version> 3.2.7 </version> <exclusion> <excache-lang </groupid> <artifactid> commons </artifactid> </explusion> </explusions>
ここでは、RocketMQの依存関係を紹介しましたが、RocketMQのApache-Langに頼りたくありませんが、依存関係を自分で紹介したいので、Apache-Langを除外しました。
ここでは、除外を宣言する場合、GroupIDとArtifactidのみが必要であり、バージョン要素は必要ないことに注意する必要があります。これは、依存関係グラフの依存関係を一意に見つけるためにGroupIDとArtifactIDのみが必要であるためです。言い換えれば、Mavenの解析された依存関係では、同じGroupIDとArtifactidであるが異なるバージョンを持つ2つの依存関係を持つことは不可能です。
settings.xml
settings.xmlは、mavenの基本構成です。多くの要素がありますので、1つずつ見てみましょう。
1。プロキシ
プロキシとは、Mavenのプロキシを意味します。ライティング方法を見てみましょう。
<Proxies> <Proxy> <id> optional </id> <active> true </active> <protocol> http </protocol> <username> proxyuser </username> <password> proxypass </proxypass> <host> proxy.host.net </host> <port> <nonproxyhosts> local.net | some.host.com </nonproxyhosts> </proxy> </proxies>
あなたの会社は、セキュリティ上の考慮事項に基づいてセキュリティ認定プロキシを使用してインターネットにアクセスする必要があるため、多くの場合、プロキシが必要です。この場合、MavenのHTTPプロキシを構成して、外部リポジトリに通常アクセスして必要なリソースをダウンロードできるようにする必要があります。複数のプロキシ要素をプロキシの下で構成できます。複数のプロキシ要素が宣言されている場合、最初にアクティブ化されたプロキシがデフォルトで有効になります。 Activeはプロキシをアクティブにするのに忠実であり、プロトコルは使用されるプロキシプロトコルを表します。もちろん、最も重要なことは、正しいホスト名（ホスト）とポート（ポート）を指定することです。プロキシサーバーに認証が必要な場合は、ユーザー名とパスワードを構成します。非プロキシホスト要素は、どのホスト名がプロキシを必要としないかを示します。 「|」を使用できます複数のホスト名を分離し、ワイルドカード「*」もサポートします。
2。リポジトリ
リポジトリは、デフォルトのリモートウェアハウスのコンポーネントが非常に大きいが、私たちのニーズを満たさず、他の中央倉庫が使用されるため、Mavenの中央倉庫を表しています。ライティング方法を見てみましょう。
<Repository> <id> public </id> <name>ローカルプライベートNexus </name> <url> http://192.168.1.6:8081/nexus/content/groups/public </url> <リリース> <Enabled> True </Enablead> <Snapshots> </snapshots> </repository>
複数のリポジトリを宣言できます。 IDは一意でなければなりません。 Mavenが提供する中央リポジトリが使用しているIDが中央にあることに特に注意してください。他のリポジトリ宣言もこのIDを使用している場合、中央リポジトリの構成が上書きされます。リリースとスナップショットがより重要です。前者は、リポジトリのリリースバージョンのダウンロードサポートを開くことを意味し、後者はリポジトリのスナップショットバージョンのダウンロードサポートを閉じることを意味します。このようにして、Mavenはリポジトリのリリースバージョンをダウンロードするためにリポジトリに移動し、リポジトリのスナップショットバージョンをダウンロードしません。
3。サーバー
ほとんどのリモートウェアハウスは認証なしでアクセスできますが、セキュリティ要因で考慮され、一部のリモート倉庫にアクセスするための認証情報を提供する必要がある場合があります。セキュリティに関する考慮事項の場合、認証情報は通常、settings.xmlにのみ配置され、サーバーは認証要素です。構成をご覧ください。
<server> <id> nexus-releases </id> <username> deployment </username> <password> deployment </password> </server>
ここで重要なのはIDです。このIDは、認証する必要があるリポジーション要素のIDとまったく同じでなければなりません。つまり、正式なIDは、認証情報とリポジトリ構成をリンクします。
4。ミラー
ウェアハウスXが倉庫Yに保存されているすべてのコンテンツを提供できる場合、倉庫Xは倉庫Yの鏡と見なすことができます。つまり、Yから取得できるコンポーネントはXから取得できます。たとえば、 "http://maven.net.cn/content/groups/public/" 「http://repo1.maven.org/maven2/」中国。地理的位置要因により、ミラーは中央の倉庫よりも高速なサービスを提供できることがよくあります。そのため、ミラーが使用されています。
ミラーの構成を見てください：
<Mirror> <id> nexus </id> <name> internal nexusリポジトリ</name> <url> http://192.168.1.6:8081/nexus/content/groups/public </url> <mirrirof>*</mirrorof> </mirror>
この例では、Mirrorfは *であり、構成がすべての中央リポジトリのミラーであり、中央リポジトリのリクエストがミラーに転送されることを示しています。他の3つの要素ID、名前、およびURLは、ミラーウェアハウスの一意の識別子、名前、アドレスを表す一般的な倉庫構成と変わりません。同様に、画像に認証が必要な場合、リポジトリ認証もIDに基づいて構成できます。
読んでくれてありがとう、私はそれがあなたを助けることができることを願っています。このサイトへのご支援ありがとうございます！