Spring5 の学習ノート -- Maven

Maven アドバンスト

この記事の主な内容

• サブモジュール開発を理解して実装する
• 集約エンジニアリングを使用してプロジェクトを迅速に構築する機能
• 継承を使用してプロジェクト構成を簡素化する機能
• ニーズに応じて生成・開発・テスト環境を構築し、さまざまな環境間で運用を切り替え可能
• Maven のプライベート サーバーについて学ぶ

Maven のライフサイクルとプラグイン

ライフサイクル

きれいな掃除段階

掃除

事前洗浄

clwan の前に行う必要がある作業を実行します。

クリーン

以前のビルドで生成されたすべてのファイルを削除します

ポストクリーン

清掃後すぐに完了する必要がある作業を実行する

デフォルトステージ

コンパイル、テスト、パッケージ化、展開などのコア作業。

サイトリリース段階

制作レポート、発行サイト

プラグイン

Maven のパッケージ化方法:

1 サブモジュール開発

1.1 サブモジュールの開発と設計

(1) 機能ごとに分ける

以前の SSM 統合開発など、現在のプロジェクトはすべて 1 つのモジュールにまとめられています。この機能は実装されましたが、まだいくつかの問題点があるため、銀行のプロジェクトを例に説明していきます。

• インターネットがそれほど発達していなかった頃、私たちは銀行の窓口や現金自動預け払い機に行って業務を行う必要がありました。
• インターネットの発達により、パソコンがあればWeb上で銀行のホームページにログインし、Uシールドを使って業務を行うことができるようになりました。
• 次に、スマートフォンの普及により、携帯電話でアプリにログインするだけで業務が行えるようになりました。

上記 3 つのシナリオは異なるタイミングで発生するため、3 つのシナリオのモジュール コードを 1 つのプロジェクトに組み込む必要がある場合、いずれかのモジュール コードに問題があると、プロジェクト全体が正常に起動できなくなり、銀行が破綻してしまいます。多くの業務が正常に処理できなくなります。だから私たちはそうします機能別プロジェクトを分割します。

(2) モジュールごとに分割

たとえば、電子商取引プロジェクトには、order と product という 2 つのモジュールがあります。order には製品に関する詳細情報が含まれる必要があるため、製品のモデル クラスが必要です。product モジュールも、次のモデル クラスを使用します。このとき、両方のモジュールにモデルクラスが存在すると、コードが重複して作成され、その後のメンテナンスコストが比較的高くなります。それらの共通部分を独立したモジュールに抽出できないか考えますが、他のモジュールがそれを使用したい場合は、サードパーティの jar パッケージの依存関係を追加するのと同じように、独自に抽出したモジュールを使用できます。これにより、コードの重複の問題が解決されます。それは私たちが言うことですフォローモジュールスプリット。

2 つのケースを分析した結果、次のことが分かりました。

• モジュール間の相互呼び出しとインターフェイスの共有を容易にするために、元のモジュールを機能に応じていくつかのサブモジュールに分割します。

ドメイン層は分割できると述べましたが、ドメイン層に加えて、次のような他の層を反対のモジュールに分割することもできます。

この場合、プロジェクト内の各レイヤーは独立して管理でき、他のレイヤーも簡単に使用できます。サブモジュール開発の意義については終わりましたが、メリットはたくさん述べましたが、それをどのように実装すればよいでしょうか。

1.2 サブモジュールの開発と実装

SSM 統合が完了しました。次に、SSM 統合プロジェクトに基づいてプロジェクトを分割します。

1.2.1 環境の準備

IDEA にデプロイし资料\maven_02_ssm、すぐに環境を準備します。デプロイが成功すると、プロジェクトの形式は次のようになります。

1.2.2 ドメイン層の抽出

ステップ 1: 新しいモジュールを作成する

という名前の jar プロジェクトを作成しますmaven_03_pojoなぜ 02 から 03 のようにプロジェクト名が作られるのでしょうか?理由は後述しますが、このブロックの名前は任意で構いません。

ステップ 2: プロジェクトにドメイン パッケージを作成する

maven_03_pojoプロジェクトにパッケージを作成し、Book クラスをパッケージにcom.itheima.domainコピーします。maven_02_ssm

ステップ 3: 元のプロジェクトのドメイン パッケージを削除する

削除後は、maven_02_ssmプロジェクトで使用されているBookクラスに次のように赤いプロンプトが表示されます。

**注意:** エラーの理由は、maven_02_ssmプロジェクト内で Book クラスが削除されているため、プロジェクトで Book クラスが見つからないため、エラーが報告されることです。

maven_02_ssm上記の問題を解決するには、 に依存関係を追加する必要がありますmaven_03_pojo。

ステップ 4: 依存関係を確立する

maven_02_ssmプロジェクトの pom.xmlに追加されたmaven_03_pojo依存関係

<dependency>
    <groupId>com.itheima</groupId>
    <artifactId>maven_03_pojo</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

依存関係が追加されたため、maven_02_ssmBook クラスは既に に存在するため、先ほどの赤いプロンプトは消えます。

ステップ 5:maven_02_ssmプロジェクトをコンパイルする

コンパイルすると、maven_02_ssmコンソールに次のエラーが表示されます。

エラー メッセージは次のとおりです。maven_02_ssmプロジェクトの依存関係の問題を解決できず、maven_03_pojojar パッケージが見つかりません。

なぜ見つからないのでしょうか?

その理由は、Maven はローカル ウェアハウスから対応する jar パッケージを検索しますが、jar パッケージがローカル ウェアハウスに存在しないため、エラーが報告されるためです。

maven_03_pojoこのプロジェクトはIDEA にあるため、maven_03_pojoプロジェクトをローカル ウェアハウスにインストールするだけで済みます。

ステップ 6: プロジェクトをローカルの倉庫にインストールする

Maven install コマンドを使用して、依存する必要があるプロジェクトをmaven_03_pojoMaven のローカル ウェアハウスにインストールします。

インストールが成功すると、インストールされた jar パッケージが対応するパスに表示されます。

**注意:** 特定のインストール場所は、自分のコンピューター上の Maven のローカル ウェアハウス構成の場所に関連しています。

maven_02_ssm再度コンパイルコマンドを実行すると正常にコンパイルできます。

1.2.3 Daoレイヤーの抽出

ステップ 1: 新しいモジュールを作成する

maven_04_daoという名前のjar プロジェクトを作成します。

ステップ 2: プロジェクトに dao パッケージを作成する

maven_04_daoプロジェクトにパッケージを作成し、BookDao クラスをパッケージにcom.itheima.daoコピーしますmaven_02_ssm

maven_04_dao解決する必要がある次の問題があります。

• Book クラスがプロジェクトmaven_04_daoの BookDao インターフェイスで見つからず、エラーが報告される

  • 解決策は、プロジェクトの pom.xml にプロジェクトmaven_04_daoを追加します。maven_03_pojo

    <dependencies>
        <dependency>
            <groupId>com.itheima</groupId>
            <artifactId>maven_03_pojo</artifactId>
            <version>1.0-SNAPSHOT</version>
        </dependency>
    </dependencies>
    

• プロジェクトの BookDao インターフェースでmaven_04_dao、Mybatis の追加、削除、変更、および注釈のエラー報告

  • このソリューションは、maven_04_daoプロジェクトの pom.xml にmybatis関連する依存関係を追加します。

    <dependencies>
        <dependency>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis</artifactId>
            <version>3.5.6</version>
        </dependency>
    
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>5.1.47</version>
        </dependency>
    </dependencies>
    

ステップ 3: 元のプロジェクトの dao パッケージを削除する

Dao パッケージを削除した後、maven_02_ssmBookServiceImpl クラスには Dao を使用するコンテンツが含まれるため、maven_02_ssmpom.xmlにmaven_04_dao依存関係を追加する必要があります。

<dependency>
    <groupId>com.itheima</groupId>
    <artifactId>maven_04_dao</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

この時点で、パッケージはmaven_02_ssmプロジェクトに追加されましたmaven_03_pojomaven_04_dao

プロジェクトを再度コンパイルするmaven_02_ssmと、次のようにエラーが再度報告されます。

エラーの原因は先ほどと同じで、Mavenがウェアハウスに見つからなかったmaven_04_daoので、現時点ではmaven_04_daoMavenのローカルウェアハウスにインストールするだけです。

ステップ 4: プロジェクトをローカル リポジトリにインストールする

Maven install コマンドを使用して、依存する必要があるプロジェクトをmaven_04_daoMaven のローカル ウェアハウスにインストールします。

インストールが成功すると、対応するパスに対応する jar パッケージがインストールされていることがわかります。

maven_02_ssm再度コンパイル命令を実行すると正常にコンパイルできます。

1.2.4 テストの実行と要約

抽出したプロジェクトを実行すると、テスト前の追加、削除、変更、確認機能が引き続き使用できます。

したがって、プロジェクトの分割には、おおよそ次のような手順があります。

(1) Mavenモジュールの作成

(2) モジュールコードの記述

モジュール開発では、最初にモジュール機能を設計し、次にコーディングする必要があります。プロジェクトは最初に開発されてから分割されることはありません。分割方法は機能ごと、モジュールごとに分割できます。

(3) mavenコマンド(installコマンド)でモジュールをローカルウェアハウスにインストールする

チーム内での開発では、モジュールの機能をチーム内で共有できるリポジトリ（プライベートサーバー）に公開する必要がありますが、プライベートサーバーについては後ほど説明します。

2 依存関係の管理

プロジェクトを独立したモジュールに分割できるようになりました。これらの独立したモジュールを他のプロジェクトで使用したい場合は、pom.xml 内のタグを使用して jar パッケージを導入するだけです。

依存関係の管理に何が関係するかについて、次のことを 1 つずつ学習していきます。

• 推移的な依存関係
• オプションの依存関係
• 依存関係を除外する

まず依存関係とは何かについて話しましょう。

依存関係とは、現在のプロジェクトを実行するために必要な jar を指します。プロジェクトには複数の依存関係を設定できます。

形式は次のとおりです。

<!--设置当前项目所依赖的所有jar-->
<dependencies>
    <!--设置具体的依赖-->
    <dependency>
        <!--依赖所属群组id-->
        <groupId>org.springframework</groupId>
        <!--依赖所属项目id-->
        <artifactId>spring-webmvc</artifactId>
        <!--依赖版本号-->
        <version>5.2.10.RELEASE</version>
    </dependency>
</dependencies>

2.1 依存関係の転送と競合の問題

前のプロジェクトのケースに戻り、Maven パネルを開くと、次のものが表示されます。

プロジェクトが依存する jar パッケージの大きな違いは、一部の依存関係の前に矢印が付いているもの>と、そうでない依存関係があることです。

では、この矢印は何を意味するのでしょうか？

手前の矢印を開くと、この jar パッケージには他の jar パッケージも含まれていることがわかります。

maven_03_pojo2 つの依存関係が dependency に読み込まれていることがわかりますが、Dependencymaven_04_dao内の依存関係は使用できるmaven_03_pojoのでしょうか?

検証は非常に簡単で、maven_02_ssmプロジェクト内の pom.xmlmaven_03_pojoの依存関係にコメントを付けるか削除するだけです。

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムが備わっている可能性があります。画像を保存して直接アップロードすることをお勧めします (img-y6bZxBoA-1689244798952) (assets/1630819768305.png)]

dependency に追加した依存関係を削除した後maven_03_pojo、 BookServiceImpl クラスを開くと、 Book クラスがまだ存在しており、通常どおり使用できることがわかります。

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムが備わっている可能性があります。画像を保存して直接アップロードすることをお勧めします (img-dOCMtS8C-1689244798952) (assets/1630819826163.png)]

実際に説明したいのはこの機能です推移的な依存関係。

依存関係は推移的です。

**説明:**A は独自のプロジェクトを表します。B、C、D、E、F、G はプロジェクトが依存する jar パッケージを表します。D1 と D2 E1 と E2 は同じ jar パッケージの異なるバージョンを表します。

(1) A は B と C に依存し、B と C は他の jar パッケージに依存するため、プロジェクト A では上記のすべての jar パッケージを使用できます。これを依存関係の転送と呼びます。

(2) 依存関係の転送には直接的な依存関係と間接的な依存関係がある

• A に対して、A は B と C に直接依存し、間接的に D1、E1、G、F、D2、および E2 に依存します。
• B と比較すると、B は D1 と E1 に直接依存し、間接的に G に依存します。
• 直接依存と間接依存は相対的な概念です

(3) 依存関係の転送が存在するため、依存関係の処理中に jar パッケージ内で競合が発生しますが、競合とは何ですか? Maven は競合をどのように解決しますか?

ここで言われていること依存関係の競合これは、プロジェクトが依存する特定の jar パッケージに複数の異なるバージョンがあるため、クラス パッケージのバージョンの競合が発生することを意味します。

状況 1: maven_02_ssm2 つの異なるバージョンの Junit 依存関係を pom.xml に追加します。

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
</dependencies>

比較して結論を​​導き出します

• 特別な優先順位: 同じリソースの異なるバージョンが同じレベルで構成されている場合、後で構成されたバージョンが以前に構成されたバージョンを上書きします。

ケース 2: パスの優先度: 依存関係に同じリソースが存在する場合、レベルが深いほど優先度は低くなり、レベルが浅いほど優先度は高くなります。

• A は B を通じて E1 に間接的に依存します
• A は C を通じて E2 に間接的に依存します
• A は間接的に E1 と E2 に依存しますが、レベルに応じて Maven が選択します。E1 は 2 級、E2 は 3 級なので、最終的には E1 が選択されます。

シナリオ 3: 宣言の優先順位: リソースが同じレベルに依存している場合、構成順序が早い方が、構成順序が後のものより優先されます。

• A は B を通じて D1 に間接的に依存します
• A は C を通じて D2 に間接的に依存します
• D1 と D2 はどちらも 2 度です。このとき、レベルに応じて選択することはできません。宣言に従って選択する必要があります。先に宣言した人がどちらを使用するかです。つまり、C よりも B が宣言されます。時間に応じて D1 が使用され、その逆も同様です。

ただし、上記の結果に応じて、意図的に覚える必要はありません。Maven がどのように選択しても、最終結果はDependenciesMaven パネルに表示されるため、どのバージョンが表示されるか、つまりどのバージョンが選択されるかが次のように表示されます。

Maven の各座標の依存関係をより包括的に表示したい場合は、Maven パネルをクリックします。show Dependencies

このビューでは、jar パッケージ間の相互依存関係を明確に表示できます。

2.2 オプションの依存関係と除外される依存関係

依存関係の転送を導入した後、次の質問について考えてみましょう。

• maven_02_ssm は maven_04_dao に依存します
• maven_04_dao は maven_03_pojo に依存します
• 依存関係が渡されるので、maven_02_ssm は maven_03_pojo の内容を使用できます。
• 現在、maven_02_ssm を maven_03_pojo に依存させたくない場合、解決策は何でしょうか?

**注意:** 実際の使用プロセスでは、maven_03_pojo を maven_02_ssm で使用する必要があります。この例は、ここでのニーズを説明するためにのみ使用されます。場合によっては、特定の要因により、maven_04_dao が依存する maven_03_pojo を他の人に使用させたくないからです。

オプション 1: オプションの依存関係

• オプションの依存関係とは、現在依存しているリソースを外部から隠すことを指します (不透明)

maven_04_daopom.xmlに、 を導入するときにmaven_03_pojo追加します。optional

<dependency>
    <groupId>com.itheima</groupId>
    <artifactId>maven_03_pojo</artifactId>
    <version>1.0-SNAPSHOT</version>
    <!--可选依赖是隐藏当前工程所依赖的资源，隐藏后对应资源将不具有依赖传递-->
    <optional>true</optional>
</dependency>

現時点では、BookServiceImpl はエラーを報告しています。これは、maven_04_dao が maven_03_pojo をオプションの依存関係として設定しているため、maven_02_ssm が maven_03_pojo のコンテンツを参照できず、Book クラスが見つからないことを示しています。

オプション 2: 依存関係を削除する

• 依存関係を除外すると、依存リソースをアクティブに切断することになります。除外されたリソースではバージョンを指定する必要はありません (必須ではありません)。

以前に、オプションの依存関係を通じて maven_03_pojo の依存関係の転送をブロックする実装をしました。除外された依存関係については、依存関係がすでに存在するという事実を指します。つまり、maven_03_pojo は依存関係の転送を通じて maven_02_ssm プロジェクトで使用されています。 , やるべきこと 除外することなので、次に maven_02_ssm の pom.xml を変更する必要があります

<dependency>
    <groupId>com.itheima</groupId>
    <artifactId>maven_04_dao</artifactId>
    <version>1.0-SNAPSHOT</version>
    <!--排除依赖是隐藏当前资源对应的依赖关系-->
    <exclusions>
        <exclusion>
            <groupId>com.itheima</groupId>
            <artifactId>maven_03_pojo</artifactId>
        </exclusion>
    </exclusions>
</dependency>

この操作の後、BookServiceImpl の Book クラスもエラーを報告します。

もちろん、exclusionsラベルはs複数の依存する jar パッケージを順番に除外できることを示しています。たとえば、maven_04_dao には junit と mybatis への依存関係があり、それらをすべて一度に除外することもできます。

<dependency>
    <groupId>com.itheima</groupId>
    <artifactId>maven_04_dao</artifactId>
    <version>1.0-SNAPSHOT</version>
    <!--排除依赖是隐藏当前资源对应的依赖关系-->
    <exclusions>
        <exclusion>
            <groupId>com.itheima</groupId>
            <artifactId>maven_03_pojo</artifactId>
        </exclusion>
        <exclusion>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
        </exclusion>
        <exclusion>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis</artifactId>
        </exclusion>
    </exclusions>
</dependency>

これら 2 つの方法を紹介した後で、それらを簡単に整理してみましょう。

• A依赖B,B依赖Cは、C依存関係の転送を通じて使用されます。次に、それに依存しないA方法を見つける必要があります。AC
• オプションの依存関係は B に設定されています<optional>が、存在するかどうかはAわかりません。C
• 依存関係の除外は A に設定されています。依存関係が存在することがわかっている<exclusions>場合は、率先してそれらを除外します。AC

2.3 依存関係の範囲

2.4 依存関係スコープの譲渡

3 集約と継承

私たちのプロジェクトは、以前の単一モジュール開発から現在のマルチモジュール開発に変更されました。プロジェクトが複数モジュール開発になると問題が発生しますが、ここでは主に 2 つの内容を学習し、聚合モジュール继承を分割した上でその 2 つの知識を使って問題を解決していきます。

3.1 集計

• サブモジュール開発後、これら 4 つのプロジェクトをローカル ウェアハウスにインストールする必要があります。現在、プロジェクトの Maven パネルからのみインストールでき、install4 つインストールする必要があります。プロジェクトが十分にある場合、それらをインストールするのは面倒です一つ一つ。
• 4 つのプロジェクトがすべて正常にインストールされている場合、ssm_pojo が変更されたときに、ssm_pojo を Maven リポジトリに再インストールする必要があります。ただし、ssm_pojo への変更が他のプロジェクト モジュールに影響を与えないようにするには、すべてのモジュールを再インストールする必要があります。すべてのモジュールを再度コンパイルする必要があります

プロジェクトの数が少ない場合は大丈夫ですが、プロジェクトが多い場合、各プロジェクトの操作を見逃したり繰り返したりしやすいので、プロジェクトを抽出してすべてのプロジェクトを管理できないか考えます。プロジェクトの場合、このプロジェクトだけを操作すれば、他のプロジェクトも同じ手順で進められるので、非常に手間がかからず省力化できるのではないでしょうか？

これは次に説明するものを使用します重合，

• いわゆる集約: 複数のモジュールを全体に編成し、同時にプロジェクトを構築するプロセスを集約と呼びます。
• 集約プロジェクト: 通常、ビジネス機能を持たない「空の」プロジェクト (唯一の pom ファイル)
• 機能: 集約プロジェクトを使用して複数のプロジェクトをグループ化でき、集約プロジェクトをビルドすることで含まれるモジュールを同期的にビルドできます。
  • プロジェクト内のモジュールが更新（変更）された場合、プロジェクト内の更新されたモジュールに関連付けられたモジュールも同時に更新されるようにする必要がありますが、このとき、集約プロジェクトを使用すると、バッチの同期ビルドの問題を解決できます。モジュール。

集約の具体的な実装手順は次のとおりです。

ステップ 1: 空の Maven プロジェクトを作成する

ステップ 2: プロジェクトのパッケージ化方法を pom に変更します。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.itheima</groupId>
    <artifactId>maven_01_parent</artifactId>
    <version>1.0-RELEASE</version>
    <packaging>pom</packaging>
    
</project>

注: プロジェクトのパッケージ化には 3 つの方法があります。

• jar: デフォルトでは、プロジェクトは Java プロジェクトです
• war: プロジェクトが Web プロジェクトであることを示します
• pom: プロジェクトが集約または継承 (後で説明します) プロジェクトであることを示します

ステップ 3: 管理対象のプロジェクトを pom.xml に追加する

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.itheima</groupId>
    <artifactId>maven_01_parent</artifactId>
    <version>1.0-RELEASE</version>
    <packaging>pom</packaging>
    
    <!--设置管理的模块名称-->
    <modules>
        <module>../maven_02_ssm</module>
        <module>../maven_03_pojo</module>
        <module>../maven_04_dao</module>
    </modules>
</project>

ステップ 4: 集約を使用してプロジェクトを均一に管理する

テストでは、maven_01_parentをcompileクリックすると、それによって管理されているすべてのプロジェクトがコンパイルされることがわかりました。ここでポリマーエンジニアリングが活躍します。

**注意:** 集約プロジェクトによって管理されているプロジェクトが実行されると、構成の順序に関係なく、プロジェクト間の依存関係に基づいて実行順序が自動的に決定されます。

アグリゲーションに関する知識の説明は終わりましたが、最後のまとめは、アグリゲーション エンジニアリングは主にプロジェクト管理に使用されるということです。

3.2 継承

集約プロジェクトを使用したプロジェクト管理が完了しました。集約プロジェクトが特定のビルド操作を実行すると、その集約プロジェクトによって管理されている他のプロジェクトも同じビルド操作を実行します。次に、マルチモジュール開発における別の問題を分析しましょう重复配置。まず、この図を見てみましょう。

• spring-webmvcはspring-jdbc3 つのプロジェクト モジュールに表示されるため、内容が重複しています。
• spring-testssm_crm と ssm_goods にのみ表示されますが、ssm_order には表示されません。重複するコンテンツがいくつかあります。
• 私たちが使用している Spring バージョンは現在 です5.2.10.RELEASE。後で Spring バージョンをアップグレードしたい場合は、すべての Spring 関連の jar パッケージを変更する必要があります。関係するプロジェクトが増えるほど、メンテナンス コストが高くなります。

上記の問題に直面して、私たちは次に学ぶことを活用しなければなりません継承する

• いわゆる継承: 2 つのプロジェクト間の関係を記述します。これは Java の継承に似ています。サブプロジェクトは親プロジェクトの構成情報を継承できます。これは依存関係の継承で一般的です。
• 効果：
  • 構成を簡素化する
  • バージョンの競合を減らす

次に、プログラムに移動して、継承がどのように実装されるかを見てみましょう。

ステップ 1: 空の Maven プロジェクトを作成し、そのパッケージ化モードを pom に設定します。

この手順は Maven で集約プロジェクトを作成する以前の方法とまったく同じであるため、新しいプロジェクトを個別に作成することも、プロジェクトを集約と直接共有することもできます。実際の開発では、集約と継承は同じプロジェクト内に置くのが一般的ですが、機能は異なります。

ステップ 2: サブプロジェクト内に親プロジェクトを設定する

親プロジェクトをmaven_02_ssm、の pom.xml にそれぞれ追加しますmaven_03_pojo。maven_04_daomaven_01_parent

<!--配置当前工程继承自parent工程-->
<parent>
    <groupId>com.itheima</groupId>
    <artifactId>maven_01_parent</artifactId>
    <version>1.0-RELEASE</version>
    <!--设置父项目pom.xml位置路径-->
    <relativePath>../maven_01_parent/pom.xml</relativePath>
</parent>

ステップ 3: サブプロジェクトの共有依存関係のインポートの問題を最適化する

1. サブプロジェクトで一般的に使用されるすべての jar パッケージを抽出し、親プロジェクトの pom.xml に保持します。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.itheima</groupId>
    <artifactId>maven_01_parent</artifactId>
    <version>1.0-RELEASE</version>
    <packaging>pom</packaging>
    
    <!--设置管理的模块名称-->
    <modules>
        <module>../maven_02_ssm</module>
        <module>../maven_03_pojo</module>
        <module>../maven_04_dao</module>
    </modules>
    <dependencies>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>5.2.10.RELEASE</version>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-webmvc</artifactId>
            <version>5.2.10.RELEASE</version>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-jdbc</artifactId>
            <version>5.2.10.RELEASE</version>
        </dependency>

        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-test</artifactId>
            <version>5.2.10.RELEASE</version>
        </dependency>

        <dependency>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis</artifactId>
            <version>3.5.6</version>
        </dependency>

        <dependency>
            <groupId>org.mybatis</groupId>
            <artifactId>mybatis-spring</artifactId>
            <version>1.3.0</version>
        </dependency>

        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>5.1.47</version>
        </dependency>

        <dependency>
            <groupId>com.alibaba</groupId>
            <artifactId>druid</artifactId>
            <version>1.1.16</version>
        </dependency>

        <dependency>
            <groupId>javax.servlet</groupId>
            <artifactId>javax.servlet-api</artifactId>
            <version>3.1.0</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.9.0</version>
        </dependency>
    </dependencies>
</project>

2. 親プロジェクトの pom.xml に抽出されたサブプロジェクトの jar パッケージを削除します。たとえば、maven_02_ssm親プロジェクトの pom.xml にある jar パッケージを削除します。

<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>com.itheima</groupId>
  <artifactId>maven_02_ssm</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>war</packaging>

  <!--配置当前工程继承自parent工程-->
  <parent>
    <groupId>com.itheima</groupId>
    <artifactId>maven_01_parent</artifactId>
    <version>1.0-RELEASE</version>
    <relativePath>../maven_01_parent/pom.xml</relativePath>
  </parent>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>

    <dependency>
      <groupId>com.itheima</groupId>
      <artifactId>maven_04_dao</artifactId>
      <version>1.0-SNAPSHOT</version>
      <!--排除依赖是隐藏当前资源对应的依赖关系-->
      <exclusions>
        <exclusion>
          <groupId>log4j</groupId>
          <artifactId>log4j</artifactId>
        </exclusion>
        <exclusion>
          <groupId>org.mybatis</groupId>
          <artifactId>mybatis</artifactId>
        </exclusion>
      </exclusions>
    </dependency>

  </dependencies>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.tomcat.maven</groupId>
        <artifactId>tomcat7-maven-plugin</artifactId>
        <version>2.1</version>
        <configuration>
          <port>80</port>
          <path>/</path>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

削除後、親プロジェクトの依存関係に対応する jar パッケージがあることがわかります。サブプロジェクトは重複した依存関係を削除しましたが、更新すると、サブプロジェクトに必要な jar パッケージがまだ存在します。

プロジェクト<parent>タグを削除すると、余分な jar パッケージの依存関係が消えることがわかります。

3. maven_04_daoプロジェクトの pom.xml 内のすべての依存関係を削除し、maven_01_parent親プロジェクトの座標を追加します。

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>com.itheima</groupId>
    <artifactId>maven_04_dao</artifactId>
    <version>1.0-SNAPSHOT</version>

    <!--配置当前工程继承自parent工程-->
    <parent>
        <groupId>com.itheima</groupId>
        <artifactId>maven_01_parent</artifactId>
        <version>1.0-RELEASE</version>
        <relativePath>../maven_01_parent/pom.xml</relativePath>
    </parent>
</project>

Maven パネルを更新して表示すると、maven_04_dao によって親プロジェクト内のすべての依存関係も導入されていることがわかります。

このようにして、最初の問題を解決し、サブプロジェクト内のパブリック jar パッケージを親プロジェクトに抽出し、依存関係を均一に追加することで、構成を簡素化し、親プロジェクトの jar パッケージのバージョンを変更することができます。変更が発生すると、すべてのサブプロジェクト内の対応する jar パッケージのバージョンもそれに応じて更新されます。

ステップ 4: サブプロジェクトの依存関係バージョンの問題を最適化する

使用されるすべての jar パッケージが親プロジェクトの pom.xml で管理されていれば簡単に思えますが、これにより、多くのプロジェクトで必要のない jar パッケージが多すぎることになります。上のこの図に見られるように:

spring-test統合メンテナンスのためにすべての依存関係が親プロジェクトに配置されると、ssm_order プロジェクトにさらに多くの jar パッケージが導入されることになります。そのような jar パッケージが多すぎると、ssm_order の「負担」にもなります。

では、一部のプロジェクトでは、jar パッケージをどのように管理し、最適化すればよいのでしょうか?

1. 親プロジェクト mavne_01_parent の pom.xml で依存関係管理を定義します。

<!--定义依赖管理-->
<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>4.12</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

2. maven_02_ssm の pom.xml 内の junit 依存関係を削除し、Maven を更新します
   

更新すると、maven_02_ssm プロジェクトの junit 依存関係が表示されないことがわかり、次の結論に達します。

<dependencyManagement>このタグは実際には jar パッケージを導入するのではなく、サブプロジェクトによって選択できる jar パッケージの依存関係を構成します。

サブプロジェクトが提供する jar パッケージを使用したい場合は、依存関係を独自に追加する必要があり、指定する必要はありません。<version>

3. maven_02_ssm の pom.xml に junit 依存関係を追加します。

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <scope>test</scope>
</dependency>

注: ここでバージョンを追加する必要はありません。この利点は、親プロジェクトの dependencyManagement タグ内のバージョンが変更されると、それに応じてサブプロジェクト内の依存関係バージョンも変更されることです。

4. maven_04_dao の pom.xml に junit 依存関係を追加します。

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <scope>test</scope>
</dependency>

このとき、親プロジェクトのラベル dependencyManagement の junit バージョンの変更に応じて、maven_02_ssm と maven_04_dao の 2 つのプロジェクトの junit バージョンが変更されます。junit を必要としないプロジェクトでは、対応する依存関係を追加する必要はありません。

ここまでで継承の学習を終了しました。要約すると、継承は 2 つのことを行うのに役立ちます。

• すべてのプロジェクトの共通の jar パッケージの依存関係を親プロジェクトの pom.xml に抽出します。これにより、サブプロジェクトを繰り返し記述する必要がなくなり、開発が簡素化されます。
• バージョン管理を実現し、メンテナンスを容易にするために、親プロジェクトの dependencyManagement タグの下にあるすべてのプロジェクトの jar パッケージを構成します。
  • dependencyManagement タグは、実際には jar パッケージを導入するのではなく、jar パッケージのバージョンを管理するだけです。
  • サブプロジェクトを導入する場合、groupId と artifactId を指定するだけでよく、バージョンは必要ありません。
  • dependencyManagement タグ内の jar パッケージのバージョンが変更されると、jar パッケージが使用されているすべてのサブプロジェクト内の対応するバージョンがそれに応じて自動的に更新されます。

最後の要約は、親プロジェクトは主に、依存する jar パッケージを迅速に構成し、プロジェクトで使用されるリソースを管理するために使用されるということです。

まとめ

継承の実装手順:

• Maven モジュールを作成し、パッケージング タイプを pom に設定します。

  <packaging>pom</packaging>
  

• 親プロジェクトの pom ファイルで依存関係を構成します (サブプロジェクトは親プロジェクトの依存関係を継承します)。通常、サブプロジェクト内のパブリック jar パッケージのみが抽出されます。

  <dependencies>
      <dependency>
          <groupId>org.springframework</groupId>
          <artifactId>spring-webmvc</artifactId>
          <version>5.2.10.RELEASE</version>
      </dependency>
      ...
  </dependencies>
  

• 親プロジェクトのサブプロジェクトでオプションの依存関係を構成する

  <dependencyManagement>
      <dependencies>
          <dependency>
              <groupId>com.alibaba</groupId>
              <artifactId>druid</artifactId>
              <version>1.1.16</version>
          </dependency>
      </dependencies>
      ...
  </dependencyManagement>
  

• 現在のプロジェクトが継承する親プロジェクトをサブプロジェクトに設定する

  <!--定义该工程的父工程-->
  <parent>
      <groupId>com.itheima</groupId>
      <artifactId>maven_01_parent</artifactId>
      <version>1.0-RELEASE</version>
      <!--填写父工程的pom文件,可以不写-->
      <relativePath>../maven_01_parent/pom.xml</relativePath>
  </parent>
  

• 親プロジェクトのオプションの依存関係の座標を使用するようにサブプロジェクトで構成します。

  <dependencies>
      <dependency>
          <groupId>com.alibaba</groupId>
          <artifactId>druid</artifactId>
      </dependency>
  </dependencies>
  

  予防：

  1. サブプロジェクトの親プロジェクトでオプションの依存関係を使用する場合、グループ ID とプロジェクト ID を指定するだけで済みます。バージョンを指定する必要はありません。バージョンの競合を避けるために、バージョンは親プロジェクトによって提供されます。

  2. サブプロジェクトは、親プロジェクトで定義されていない依存関係を定義することもできますが、統合バージョンの親プロジェクトで管理することはできません。

3.3 集約と継承の違い

3.3.1 集約と継承の違い

二人の間の役割:

• 集約は、プロジェクトを迅速に構築し、プロジェクトを管理するために使用されます。
• 継承は、サブプロジェクトで使用される jar パッケージのバージョンを迅速に構成および管理するために使用されます。

集約と継承の類似点:

• 集約と継承のための pom.xml ファイルのパッケージ化方法は pom であり、2 つの関係を同じ pom ファイルに作成できます。
• 集約と継承は両方とも設計モジュールであり、実際のモジュール コンテンツはありません。

集約と継承の違いは次のとおりです。

• 集約は、現在のモジュール内の関係を構成することであり、どのモジュールが集約に参加しているかを感知できます。
• 継承とはサブモジュール内の関係を設定することですが、親モジュールはどのサブモジュールがそれを継承するかを認識できません。

ここまでで集約と継承の区別ができたと思いますが、集約と継承のプロジェクト構築には少々面倒な点があり、集約プロジェクトに手動でタグを追加する必要があり、すべてのサブプロジェクトにタグを付けますmodules。parent間違えた場合はどうすればよいですか?

3.3.2 IDEA による集約および継承プロジェクトの構築

実際、IDEA はすでに集約および継承プロジェクトを迅速に構築するのに役立ちます。具体的な実装手順は次のとおりです。

ステップ 1: Maven プロジェクトを作成する

空の Maven プロジェクトを作成し、プロジェクト内のsrcディレクトリを削除します。このプロジェクトは、集約プロジェクトおよび親プロジェクトとして機能します。

ステップ 2: サブプロジェクトを作成する

このプロジェクトは集約プロジェクトによって管理でき、親プロジェクトを継承します。

作成に成功すると、maven_parent が集約プロジェクトと親プロジェクトになりますが、maven_web には maven_parent を継承した親タグがあり、設定が難しい内容は自動生成されます。

上記の方法によれば、誰でも自分のニーズに応じてサブモジュール プロジェクトを構築できます。

4物件

この章では、次の 2 つの内容を学習します。

• 属性
• バージョン管理

属性は、サブモジュール開発プロジェクトに存在する問題を解決し続けます。バージョン管理は主に、現在主流のバージョン定義方法を理解することです。

4.1 プロパティ

4.1.1 問題分析

内容を説明する前に、まず問題を分析しましょう。

以前は、プロジェクトで使用される jar パッケージのバージョンを親プロジェクトの dependencyManagement タグで一元管理していましたが、タグ内に次の内容がある場合:

今すぐ Spring バージョンを更新したい場合は、複数の jar パッケージのバージョンを更新する必要があることがわかりますが、この場合、プログラムの問題を引き起こす変更が欠落している可能性がまだあります。変更する方が面倒です。

問題が明確になった後、それを解決する必要がある場合は、Java の基礎で学んだ変数を参照し、変数を宣言し、その変数を他の場所で使用することができます。使用される変数はそれに応じて変更されます。

4.1.2 解決策の手順

ステップ 1: 親プロジェクトでプロパティを定義する

<properties>
    <spring.version>5.2.10.RELEASE</spring.version>
    <junit.version>4.12</junit.version>
    <mybatis-spring.version>1.3.0</mybatis-spring.version>
</properties>

ステップ 2: 依存バージョンを変更する

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-core</artifactId>
    <version>${spring.version}</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>${spring.version}</version>
</dependency>
<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-jdbc</artifactId>
    <version>${spring.version}</version>
</dependency>

現時点では、親プロジェクトのプロパティ タグで保持されている jar パッケージのバージョンを更新するだけでよく、すべてのサブプロジェクトのバージョンもそれに応じて更新されます。もちろん、Spring 関連のバージョンを維持することに加えて、次のように他の jar パッケージ バージョンを抽出することもできるため、プロジェクト内のすべての jar パッケージ バージョンを均一に維持できます。

<!--定义属性-->
<properties>
    <spring.version>5.2.10.RELEASE</spring.version>
    <junit.version>4.12</junit.version>
    <mybatis-spring.version>1.3.0</mybatis-spring.version>
</properties>

4.2 設定ファイル読み込みプロパティ

すでに Maven にプロパティを導入しましたが、Maven を使用して、依存する jar パッケージのバージョンを Maven で集中管理できるようになりました。しかし、Maven による属性の管理範囲を広くしたいという新たな要求があります。たとえば、以前のプロジェクトでは、jdbc.propertiesこの設定ファイル内の属性も Maven で管理できるでしょうか?

答えは「はい」です。具体的な実装手順は次のとおりです。

ステップ 1: 親プロジェクト定義のプロパティ

<properties>
   <jdbc.url>jdbc:mysql://127.1.1.1:3306/ssm_db</jdbc.url>
</properties>

ステップ 2: jdbc.properties ファイル内のプロパティを参照する

jdbc.properties で、jdbc.url の値から Maven 構成プロパティを直接取得します。

jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=${jdbc.url}
jdbc.username=root
jdbc.password=root

ステップ 3: Maven フィルター ファイルのスコープを設定する

デフォルトでは、Maven はsrc\main\resourcesパッケージ化のために現在のプロジェクトからファイルを読み取ります。ここで、パッケージ化する必要があるリソース ファイルは maven_02_ssm の下にあり、構成を通じて特定のリソース ディレクトリを指定する必要があります。

<build>
    <resources>
        <!--设置资源目录-->
        <resource>
            <directory>../maven_02_ssm/src/main/resources</directory>
            <!--设置能够解析${}，默认是false -->
            <filtering>true</filtering>
        </resource>
    </resources>
</build>

**注意: **ディレクトリ パスの前に追加する理由は../、maven_02_ssm が親プロジェクトの pom.xml パスの上のディレクトリにあるため、追加する必要があるためです。

変更後、maven_02_ssm プロジェクトのリソース ディレクトリには次のようにさらに多くのものがあることに注意してください。

ステップ 4: 動作するかどうかをテストする

テストする場合は、maven_02_ssm プロジェクトをパッケージ化し、パッケージ化結果で最終的に生成されたコンテンツが Maven で構成されたコンテンツであるかどうかを確認するだけで済みます。

以上で属性管理は完了しましたが、maven_02_ssmプロジェクトだけでなく親プロジェクトで属性管理が必要なだけでなく、設定が必要なプロジェクトが複数ある場合、どのように実装すればよいのかという問題が一つ解決できていません。

方法 1:

<build>
    <resources>
        <!--设置资源目录，并设置能够解析${}-->
        <resource>
            <directory>../maven_02_ssm/src/main/resources</directory>
            <filtering>true</filtering>
        </resource>
        <resource>
            <directory>../maven_03_pojo/src/main/resources</directory>
            <filtering>true</filtering>
        </resource>
        ...
    </resources>
</build>

設定することもできますが、プロジェクトが十分にある場合、この設定も比較的面倒です。

方法 2:

<build>
    <resources>
        <!--
			${project.basedir}: 当前项目所在目录,子项目继承了父项目，
			相当于所有的子项目都添加了资源目录的过滤
		-->
        <resource>
            <directory>${project.basedir}/src/main/resources</directory>
            <filtering>true</filtering>
        </resource>
    </resources>
</build>

**注意:** パッケージ化プロセス中に次のエラーが報告された場合:

[外部リンク画像の転送に失敗しました。ソース サイトにはリーチ防止メカニズムが備わっている可能性があります。画像を保存して直接アップロードすることをお勧めします (img-NwRrpgpy-1689244799007) (assets/1630948929828.png)]

その理由は、Maven はプロジェクトが Web プロジェクトであることを検出すると、Web プロジェクトの入り口である web.xml [構成ファイルの構成方法] を探し、見つからない場合はエラーを報告するためです。

解決策 1: src\main\webapp\WEB-INF\web.xml ファイルを maven_02_ssm プロジェクトに追加する

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">
</web-app>

解決策 2: war をパッケージ化するように Maven を構成する場合、web.xml チェックを無視する

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-war-plugin</artifactId>
            <version>3.2.3</version>
            <configuration>
                <failOnMissingWebXml>false</failOnMissingWebXml>
            </configuration>
        </plugin>
    </plugins>
</build>

上記で使用したカスタム プロパティはすべて、Maven の組み込みシステム プロパティである ${project.basedir} を除き、Maven のカスタム プロパティです。

Maven のプロパティは次のように分類されます。

• カスタム属性 (一般的に使用される)
• 組み込みプロパティ
• 設定プロパティ
• Java システムのプロパティ
• 環境変数のプロパティ
  

これらのプロパティを具体的に表示する方法は次のとおりです。

cmdコマンドラインに入力しますmvn help:system

具体的な使い方としては${key}、取得する場合に使用し、等号の左側がキー、等号の右側が値で、例えば赤線の値を取得する場合、対応する書き方は となります${java.runtime.name}。

4.3 バージョン管理

このバージョン管理によって解決される問題は、Maven がプロジェクトを作成し、他の人のプロジェクトを参照するときに、次のような問題が発生することです。

ここにはスナップショットとリリースという 2 つの単語がありますが、これは何を意味しますか?

Maven 倉庫の住所を公開しますhttps://mvnrepository.com/

jar パッケージのバージョン定義には、一般的に使用される 2 つのプロジェクト バージョンがあります。

• SNAPSHOT（スナップショット版）
  • プロジェクトの開発過程で一時的に出力されるバージョンをスナップショットバージョンと呼びます
  • スナップショットのバージョンは開発の進行に応じて継続的に更新されます
• RELEASE（リリースバージョン）
  • プロジェクト開発が一定のマイルストーンに達すると、より安定したバージョンがチーム外部にリリースされ、このバージョンに対応するコンポーネント ファイルは安定しています。
  • その後機能を開発しても現在のリリース版の内容は変更されません、このバージョンをリリース版と呼びます。

上記のプロジェクト バージョンに加えて、いくつかのリリース バージョンがよく見られます。

• アルファ版: 内部ベータ版、多くのバグがあり、常に新機能が追加される不安定な内部バージョン
• ベータ バージョン: パブリック ベータ バージョン、不安定 (アルファより安定)、比較的多くのバグと新しい機能が常に追加されています
• デジタルのみのバージョン

これらのバージョンについては、誰もが簡単に理解するだけで済みます。

5 マルチ環境構成とアプリケーション

多环境开发このセクションでは、と の2 つのコンテンツについて説明します。跳过测试

5.1 マルチ環境開発

• 私たちは通常、独自の開発環境で開発を行っています。
• 開発が完了したら、テスターがテストできるように、開発した機能をテスト環境にデプロイする必要があります。
• テスターがテストに合格したら、オンラインで使用できるようにプロジェクトを実稼働環境にデプロイします。
• このとき問題となるのは、環境ごとに構成が異なることです。たとえば、3 つの環境すべてで 1 つのデータベースを使用することは不可能なので、データベース URL の構成が 3 つ存在することになります。
• プロジェクト内でどのように設定すればよいでしょうか?
• 異なる環境間で構成を切り替えるにはどうすればよいですか?

Maven には、開発者が使用中に環境をすばやく切り替えることができるように、複数の環境を構成するための設定が用意されています。具体的な実装手順:

ステップ 1: 親プロジェクトで複数の環境を構成し、デフォルトのアクティベーション環境を指定する

<profiles>
    <!--开发环境-->
    <profile>
        <id>env_dep</id>
        <properties>
            <jdbc.url>jdbc:mysql://127.1.1.1:3306/ssm_db</jdbc.url>
        </properties>
        <!--设定是否为默认启动环境-->
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
    </profile>
    <!--生产环境-->
    <profile>
        <id>env_pro</id>
        <properties>
            <jdbc.url>jdbc:mysql://127.2.2.2:3306/ssm_db</jdbc.url>
        </properties>
    </profile>
    <!--测试环境-->
    <profile>
        <id>env_test</id>
        <properties>
            <jdbc.url>jdbc:mysql://127.3.3.3:3306/ssm_db</jdbc.url>
        </properties>
    </profile>
</profiles>

ステップ 2: インストールを実行して env_dep 環境が有効かどうかを確認する

表示された結果は次のとおりです。

ステップ 3: デフォルト環境を実稼働環境に切り替える

<profiles>
    <!--开发环境-->
    <profile>
        <id>env_dep</id>
        <properties>
            <jdbc.url>jdbc:mysql://127.1.1.1:3306/ssm_db</jdbc.url>
        </properties>
    </profile>
    <!--生产环境-->
    <profile>
        <id>env_pro</id>
        <properties>
            <jdbc.url>jdbc:mysql://127.2.2.2:3306/ssm_db</jdbc.url>
        </properties>
        <!--设定是否为默认启动环境-->
        <activation>
            <activeByDefault>true</activeByDefault>
        </activation>
    </profile>
    <!--测试环境-->
    <profile>
        <id>env_test</id>
        <properties>
            <jdbc.url>jdbc:mysql://127.3.3.3:3306/ssm_db</jdbc.url>
        </properties>
    </profile>
</profiles>

ステップ 4: インストールを実行し、env_pro 環境が有効になっているかどうかを確認する

表示された結果は、jdbc:mysql://127.2.2.2:3306/ssm_db

異なる環境間で切り替えることは可能ですが、各スイッチは手動で変更する必要があります。コードを変更せずに環境の切り替えを完了するにはどうすればよいですか?

ステップ 5: 環境切り替えを実装するためのコマンドライン

ステップ 6: インストールを実行し、env_test 環境が有効になっているかどうかを確認する

表示された結果は、jdbc:mysql://127.3.3.3:3306/ssm_db

要約すると、複数の環境間の切り替えには次の 2 つの手順だけが必要です。

• 親プロジェクトで複数の環境を定義する

  <profiles>
  	<profile>
      	<id>环境名称</id>
          <properties>
          	<key>value</key>
          </properties>
          <activation>
          	<activeByDefault>true</activeByDefault>
          </activation>
      </profile>
      ...
  </profiles>
  

• 複数の環境の使用 (ビルドプロセス)

  mvn 指令 -P 环境定义ID[环境定义中获取]
  

5.2 テストのスキップ

install先に命令を実行すると、Maven は上から下の順に命令を実行し、毎回実行されますtest。

test存在意義があるから、

• パッケージ化またはインストールするたびにプログラムの正確性を保証できます。テストに合格し、プログラムを変更せずにパッケージングまたはインストール コマンドを再度実行すると、順次実行されるため、テストが再度実行されます。少し時間がかかります。
• 機能開発のプロセスでは、まだ開発されていないモジュールがあり、テストを通過できないことがありますが、その一部を急いでパッケージ化したい場合、テスト環境の障害によりパッケージ化に失敗します。

上記の状況が発生した場合、テストをスキップして次のビルド コマンドを実行します。具体的な実装方法は多数あります。

方法 1: IDEA ツールでスキップ テストを実装する

写真のボタンはToggle 'Skip Tests' Mode、

トグルはスイッチングと訳され、テストと非テストの切り替えを意味します。

1 回クリックすると、次のようなテスト水平線の画像が表示されます。

これはテストが終了したことを意味し、再度クリックするとテストが復元されます。

この方法は最も単純ですが、少し "暴力的" で、すべてのテストがスキップされます。スキップするテストとスキップしないテストをより正確に制御したい場合は、構成プラグイン メソッドを使用する必要があります。

方法 2: テストをスキップするようにプラグインを構成する

親プロジェクトの pom.xml にテスト プラグイン構成を追加します。

<build>
    <plugins>
        <plugin>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.12.4</version>
            <configuration>
                <skipTests>false</skipTests>
                <!--排除掉不参与测试的内容-->
                <excludes>
                    <exclude>**/BookServiceTest.java</exclude>
                </excludes>
            </configuration>
        </plugin>
    </plugins>
</build>

SkipTests: true の場合はすべてのテストをスキップし、false の場合はテストをスキップしません

excludes: テストに参加しない、つまり除外されるテストクラスは、skipTests が false の場合に設定されます。

include: どのテスト クラスがテストに参加する必要があるか、つまり、skipTests が true の場合に設定される組み込みのテスト クラス

方法 3: コマンドラインでテストをスキップする

Maven コマンドラインを使用して、mvn 指令 -D skipTests

予防：

• 実行されるプロジェクトのビルド命令にはテスト ライフ サイクルが含まれている必要があります。含まれていない場合は効果がありません。たとえば、コンパイル ライフ サイクルは、テスト ライフ サイクルを経ずに実行されます。
• このコマンドは、IDEA を使用せずに cmd コマンド ラインを使用してテストをスキップするために直接使用できます。cmd は pom.xml が配置されているディレクトリで実行する必要があることに注意してください。

6つのプライベートサーバー

このセクションでは主に次のことを学習します。

• プライベートサーバーの導入
• プライベートサーバー倉庫分類
• リソースのアップロードとダウンロード

まず、プライベートサーバーとは何ですか?

6.1 プライベートサーバーの概要

チーム開発状況分析

(1) ssm_crm の開発責任者は Zhang San です。彼自身が ssm_pojo モジュールを作成しました。これを使用したい場合は、ssm_pojo をローカル ウェアハウスに直接インストールしてください。

(2) Li Si は ssm_order の開発責任者であり、Zhang San が作成した ssm_pojo モジュールを使用する必要がありますが、現時点で Zhang San が作成した ssm_pojo モジュールを Li Si に渡すにはどうすればよいですか?

(3) 直接コピーすると、チーム間のjarパッケージ管理が非常に混乱し、コンテナにエラーが発生するため、現時点では、作成したプロジェクトを中央倉庫にアップロードできるかどうかを検討しています。オンラインで直接ダウンロードできます。

(4) Maven のセントラル ウェアハウスでは自分の jar パッケージのプライベート アップロードが許可されていないため、考え方を変えてセントラル ウェアハウスに似たものを自分たちで構築し、独自のコンテンツをアップロードすると、他の人がそこから jar パッケージをダウンロードできるようにする必要があります。

(5) この中央倉庫に似たものは、次に学習するものですプライベートサーバー

ここには 2 つの概念があり、1 つはプライベート サーバー、もう 1 つは中央ウェアハウスです。

プライベートサーバー: Maven リソースを保存するために社内に構築されたサーバー

リモート リポジトリ: Maven リソースを保存するために Maven 開発チームによって維持されるサーバー

それで：

• プライベートサーバーは、チーム内のリソース共有とリソース同期の問題を解決するために使用される独立したサーバーです。

Maven プライベート サーバーを構築するにはさまざまな方法がありますが、より一般的に使用される実装方法の 1 つを紹介しましょう。

• ネクサス
  • Sonatype の Maven プライベート サーバー製品
  • ダウンロードアドレス: https://help.sonatype.com/repomanager3/download

6.2 プライベートサーバーのインストール

ステップ 1: ダウンロードして解凍する

资料\latest-win64.zip空のディレクトリに解凍されます。

ステップ 2: Nexus を起動する

cmd を使用して解凍ディレクトリに入りnexus-3.30.1-01\bin、次のコマンドを実行します。

nexus.exe /run nexus

以下の内容が表示されれば起動成功です。

ステップ 3: ブラウザアクセス

アクセスアドレスはhttp://localhost:8081です。

ステップ 4: 初回ログイン時にパスワードをリセットする

ユーザー名とパスワードを入力してログインします。ログインに成功すると、次のページが表示されます。

「次へ」をクリックすると、新しいパスワードを再入力する必要があります。以下と一致させるために、パスワードを次のように変更してください。admin

匿名アクセスを実行するかどうかを設定します

「完了」をクリックします

この時点で、プライベート サーバーは正常にインストールされました。いくつかの基本的な構成情報を変更したい場合は、以下を使用できます。

• 基本的な構成情報を変更する
  • インストール パスの下の etc ディレクトリにある nexus-default.properties ファイルには、デフォルトのアクセス ポートなどの nexus の基本構成情報が保存されます。
• サーバー実行構成情報を変更する
  • インストール パスの下の bin ディレクトリにある nexus.vmoptions ファイルには、デフォルトの占有メモリ領域など、nexus サーバの起動に対応する設定情報が保存されます。

6.3 プライベートサーバーウェアハウスの分類

プライベートサーバーリソースの操作プロセスの分析:

(1) プライベートサーバーがない場合、自分たちで作成したサービスは Maven のローカルウェアハウスにインストールされます。

(2) プライベート サーバーにもウェアハウスがあり、リソースをプライベート サーバーにアップロードし、最終的にプライベート サーバーのウェアハウスに置く必要があります。

(3) あなたがアップロードしたリソースを他の人が使用したい場合は、プライベートサーバーの倉庫からリソースを取得する必要があります。

(4) 使用したいリソースが自分で作成したものではなく、リモートの中央ウェアハウスにあるサードパーティの jar パッケージである場合、リモートの中央ウェアハウスからダウンロードする必要があります。リモート中央倉庫 (中央倉庫サーバーは海外にあります)

(5) プライベート サーバーの場合は、リモートの中央倉庫からダウンロードされたサードパーティの jar パッケージを特別に保存するための別の倉庫を準備します。最初の訪問時にリモートの中央倉庫からダウンロードされたサードパーティの jar パッケージがない場合は、次の場所に移動します。リモートの中央倉庫にアクセスしてダウンロードします。次回アクセスした場合は、プライベート サーバーから直接ダウンロードします。

(6)バージョン管理の導入時に前述したSNAPSHOTようにRELEASE、これら 2 種類の jar パッケージを同じウェアハウスに置くと混乱するため、プライベート サーバーはこれら 2 種類の jar パッケージを別のウェアハウスに置きます。

(7) 上では 3 つの倉庫があり、1 つは保管用SNAPSHOT、もう 1 つは保管用RELEASE、もう 1 つはリモートの倉庫からダウンロードされたサードパーティの jar パッケージを保管することを紹介しましたが、どの倉庫からリソースを入手すればよいでしょうか? ?

(8) アクセスを容易にするために、すべての倉庫をグループに編成し、リソースを取得するには倉庫グループにアクセスするだけで済みます。

すべてのプライベート サーバー ウェアハウスは、次の 3 つの主要なカテゴリに分類されます。

ホストされたリポジトリがホストされている

• 中央リポジトリから取得できないリソースを保存する
  • 独立した研究開発
  • Oracle などのサードパーティの非オープンソース プロジェクトは有料製品であるため、中央倉庫がありません。

プロキシ ウェアハウス プロキシ

• エージェントのリモート倉庫、ネクサス経由で中央倉庫などの他の公共倉庫にアクセス

倉庫グループ

• 複数の倉庫を 1 つのグループにグループ化して構成を簡素化する
• ウェアハウス グループはリソースを保存できず、デザイン ウェアハウスです。
  

6.4 ローカルウェアハウスアクセスプライベートサーバー構成

• 開発したモジュールはIDEAを通じてプライベートサーバーにアップロードされ、プロセスはローカルのMavenを経由します。
• ローカル Maven は、プライベート サーバーのアクセス アドレスと、プライベート サーバーにアクセスするためのユーザー名とパスワードを知っている必要があります。
• プライベート サーバーには多くのウェアハウスがあります。Maven は最終的にどのウェアハウスにリソースをアップロードしますか?
• Maven をダウンロードするときは、ユーザー名とパスワードをプライベート サーバーに移動して、ダウンロードする対応するウェアハウス グループを見つけて、それを IDEA に渡す必要があります。
  

ローカルの Maven 構成ファイルで上記の内容settings.xmlを構成する必要があります。

ステップ 1: プライベート サーバー上でウェアハウスを構成する

例証します:

ステップ 5 と 6 では、ithema-snapshot リポジトリを作成します。

ステップ 7 と 8 では、問題リリース ウェアハウスを作成します。

ステップ 2: プライベート サーバーへのローカル Maven アクセス許可を構成する

<servers>
    <server>
        <id>itheima-snapshot</id>
        <username>admin</username>
        <password>admin</password>
    </server>
    <server>
        <id>itheima-release</id>
        <username>admin</username>
        <password>admin</password>
    </server>
</servers>

ステップ 3: プライベートサーバーのアクセスパスを構成する

<mirrors>
    <mirror>
        <!--配置仓库组的ID-->
        <id>maven-public</id>
        <!--*代表所有内容都从私服获取-->
        <mirrorOf>*</mirrorOf>
        <!--私服仓库组maven-public的访问路径-->
        <url>http://localhost:8081/repository/maven-public/</url>
    </mirror>
</mirrors>

Alibaba Cloud Maven プライベート サーバー アドレスの影響を回避するために、以前に設定した Alibaba Cloud Maven プライベート サーバー イメージ アドレスをコメント アウトし、演習の完了後に復元することをお勧めします。

この時点で、ローカル ウェアハウスはプライベート サーバーと対話できるようになります。

6.5 プライベートサーバーリソースのアップロードとダウンロード

ローカル ウェアハウスとプライベート サーバー間の接続が確立されました。次に、リソースをプライベート サーバーにアップロードおよびダウンロードする必要があります。具体的な実装手順は次のとおりです。

ステップ 1: プロジェクトをプライベート サーバーにアップロードする特定の場所を構成する

 <!--配置当前工程保存在私服中的具体位置-->
<distributionManagement>
    <repository>
        <!--和maven/settings.xml中server中的id一致，表示使用该id对应的用户名和密码-->
        <id>itheima-release</id>
         <!--release版本上传仓库的具体地址-->
        <url>http://localhost:8081/repository/itheima-release/</url>
    </repository>
    <snapshotRepository>
        <!--和maven/settings.xml中server中的id一致，表示使用该id对应的用户名和密码-->
        <id>itheima-snapshot</id>
        <!--snapshot版本上传仓库的具体地址-->
        <url>http://localhost:8081/repository/itheima-snapshot/</url>
    </snapshotRepository>
</distributionManagement>

ステップ 2: リソースをプライベート サーバーに公開する

または、Maven コマンドを実行します。

mvn deploy

知らせ：

公開するプロジェクトは、distributionManagement独自の pom.xml または親プロジェクトでタグを構成する必要があります。これにより、子プロジェクトが親プロジェクトを継承できるようになります。

リリースは成功し、プライベート サーバーで確認できます。

リリースは itheima-snapshot ウェアハウスにあります。itheima-release ウェアハウスにリリースしたい場合は、プロジェクト pom.xml のバージョンを RELEASE に変更する必要があります。

アップロードされたリソースを削除したい場合は、インターフェース上で削除できます。

プライベート サーバーに対応する jar がない場合は、中央のウェアハウスからダウンロードされるため、非常に時間がかかります。Alibaba Cloud から依存関係をダウンロードするようにプライベート サーバーを設定できます。

この時点で、プライベート サーバーの構築は完了しました。比較的面倒ではありますが、手順は比較的固定されています。後で必要になった場合は、上記の手順を参照して、段階的に構築を完了できます。