前書き
- SpringBootServletInitializerを継承し、configureメソッドをオーバーライドします
- spring-boot-starter-tomcatのスコープが提供に変更されました
- 梱包方法を戦争に変更する
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
<packaging>war</packaging>
この質問は通常、スコープとその役割に精通しているかどうかを確認するために求められます。スコープに答えるだけ
Mavenの関連知識を簡単に紹介しましょう
Mavenの前日
新しいテクノロジーを学ぶ小さな個人的な感覚は、歴史的な観点からこの新しいテクノロジーが出現した理由と、それが私たちの解決にどのような問題を助けたかを見る必要があります。Mavenがなかったときのことを思い出してみましょう。
- プロジェクトを開発するには、他の人が作成したjarパッケージを使用する必要があります。最初にオープンソースのjarパッケージをダウンロードして、プロジェクトのlibディレクトリに配置し、このディレクトリをCLASSPATHに追加します(Java実行環境に実行するJavaプログラムに必要なクラスまたはパッケージを見つけることができるディレクトリ)
- a.jarをダウンロードしたところ、a.jarもb.jarに依存する必要があることがわかりました。次に、b.jarパッケージをダウンロードして、実行を開始しました。
- 運が良ければ、すべての依存関係を追加した後、プロジェクトを適切に実行できるようになります。運が良ければ、バージョンの問題が発生します。たとえば、a.jarがb.jarを呼び出すと、b.jarにはこのメソッドがまったくないことがわかります。他のバージョンでのみ使用できます。これで問題ありません。依存関係と適応を探すだけです。バージョンには時間がかかる場合があります
- そして、コードをgitにアップロードするときは、これらすべてのライブラリをアップロードする必要があります。他の人が私たちのコードをダウンロードするとき、彼らはライブラリもダウンロードする必要がありますが、これは本当に時間がかかります
このとき、MavenはJavaの世界でパッケージ管理ツールとして登場しました。もちろん、Javaの世界には、gradleなどの他のパッケージ管理ツールもあります。yumがLinuxの世界のパッケージ管理ツールであり、webpackがフロントエンドの世界のパッケージ管理ツールであるように
Mavenリポジトリの種類
Mavenがjarパッケージを探すプロセスは、次のようになります。最初にローカルウェアハウスで見つけ、次にプライベートサーバー(構成されている場合)に移動し、次に中央ウェアハウス(http://repo1.maven.org/)に移動します。 maven2 /、Mavenチームはメンテナンスを担当します)
中央倉庫から見つかった後、コピーはプライベートサーバーとローカル倉庫に配置され、プライベートサーバーから見つかった場合はローカル倉庫にもコピーが配置されます。
Mavenをインストールした後、confディレクトリにsettings.xmlファイルがあります。このファイルには多くの構成アイテムがあります。この構成ファイルについては、後で詳しく説明します。
<!-- localRepository
| The path to the local repository maven will use to store artifacts.
|
| Default: ${user.home}/.m2/repository
<localRepository>/path/to/local/repo</localRepository>
-->
この構成ファイルには、Mavenのデフォルトのローカルウェアハウスアドレスが$ {user.home} /。m2 / repositoryであるというこの段落があります(もちろん、ローカルウェアハウスのアドレスをリセットできます。上記はテンプレートです)。私はウィンドウコンピューターです。このディレクトリを
見て、ローカルに保存されているjarパッケージがたくさんあることを確認してください。もちろん、プライベートサーバーを構成する場合は、settings.xmlでも構成されます。多くのチュートリアルを検索してそれらを繰り返さないでください。
プライベートサーバーを構築することには多くの利点があります。会社では、他の同僚が使用できるように、いくつかのパブリック基本コンポーネントを開発してプライベートサーバーに配置できます。
Mavenのデフォルト構成
Mavenプロジェクトの全体的な構造は次のようになっていますが、Mavenプロジェクトのファイル構造がこのようになっているのはなぜですか?
これはMavenの機能について話す必要があり、設定よりも規則の方が優れています。
Mavenは、デフォルトで$ {project.basedir} / src / main / javaをプロジェクトのソースコードディレクトリとして構成し、
$ {project.basedir} / src / main / testをプロジェクトのテストコードディレクトリとして構成します、
$ {project.basedir} / targetプロジェクトとして出力ディレクトリなどをコンパイルします。
Spring Bootは、設定より規約の具体化です。Springmvcを使用する場合は、ビューリゾルバーと自動パッケージスキャンを構成する必要があります。SpringBootフレームワークを使用すると、構成する必要はまったくありません。
詳細なMavenプロジェクト
インストールは非常に簡単で、紹介はしませんし、個別にダウンロードしませんでした。通常、Ideaに付属のMavenを使用します。ダウンロード後のディレクトリ構造は次のとおりです。
binディレクトリ:
このディレクトリには、mvnによって実行されるスクリプトが含まれています。これらのスクリプトは、Javaコマンドの構成、クラスパスおよび関連するJavaシステムプロパティの準備、およびJavaコマンドの実行に使用されます。
ブートディレクトリ:
このディレクトリには、plexus-classworlds-2.5.2.jarという1つのファイルのみが含まれています。Plexus-classworldsはクラスローダーフレームワークです。デフォルトのJavaクラスローダーと比較して、構成を容易にするためのより豊富な構文を提供します。Mavenはこのフレームワークを使用して独自のクラスライブラリをロードします。
confディレクトリ:
このディレクトリには、非常に重要なファイルsettings.xmlが含まれています。このファイルを直接変更することで、マシン上でmavenの動作をグローバルにカスタマイズできます。これは、すべてのユーザーに有効です。一般に、ファイルを〜/ .m2 /ディレクトリ(〜はユーザーのホームディレクトリを表し、Windowsでは〜はC:\ Users \ Peng、Pengはエディタのユーザー名)にコピーしてから、ファイル、ユーザーレベルでMavenの動作をカスタマイズします。
Libディレクトリ:
このディレクトリには、Mavenランタイムに必要なすべてのJavaクラスライブラリが含まれています。Maven自体はモジュールで開発されているため、ユーザーはmaven-core-3.0.jar、maven-model-3.0.jarなどのファイルを表示できます。 、commons-cli-1.2.jar、commons-lang-2.6.jarなど、Mavenで使用されるサードパーティの依存関係もいくつかあります。、
詳細なsettings.xml構成ファイル
settings.xmlファイルについて詳しく説明します。このファイルはMavenの動作をカスタマイズできます。前述のように、settings.xmlは〜/ .m2 / settings.xmlの2つの場所に配置できます(デフォルトでは使用できません。必要です。自分でコピーする)そして$ {maven.home} /conf/setting.xml
これら2つの構成ファイルのロード順序は、他のユーザーに影響を与えないように、〜/ .m2 / settings.xml> $ {maven.home} /conf/setting.xmlであるため、confの下のsettings.xmlをホームにコピーします。ディレクトリ、ユーザーレベルでMavenの動作をカスタマイズします。
これは、環境変数の構成に似ています。WindosとLinuxはどちらも、システムレベルの環境変数とユーザーレベルの環境変数を構成できます。Linuxについて説明します。/etc/profileで構成されるのは、システムレベルの環境変数です。〜 /。 bash_profileは、ユーザーレベルの環境変数で構成されます
さまざまな構成項目が非常に多く、ミラーウェアハウスのセットアップ(Alibaba Cloudは中国でより使用されています)、プロキシのセットアップ、詳細はありません
Mavenで一般的に使用されるコマンド
コマンド | 説明 |
---|---|
mvn -version | バージョン情報を表示する |
mvn clean | ターゲットディレクトリを削除します |
mvnコンパイル | src / main / javaの下のソースコードをコンパイルします |
mvnパッケージ | パッケージ化、ターゲットの下でjarパッケージまたはwarパッケージを生成 |
mvnテスト | src / test / javaでTestで始まるクラスまたはTestで終わるクラスのテストケースを実行します |
mvnインストール | 他のモジュールで使用するために、jarパッケージまたはwarパッケージをパッケージ化してローカルウェアハウスにコピーします |
mvnデプロイ | パッケージ化されたファイルをプライベートサーバーに公開する |
mvn依存関係:ツリー | プロジェクトの依存関係ツリー全体を印刷します |
もちろん、mvn cleanpackage
を使用してパッケージをクリーンアップすることもでき
ますmvnclean package -DskipTests = trueを使用してパッケージをクリーンアップし、テストケースをスキップします
mvn clean installパッケージをクリーンアップし、jarパッケージまたはwarパッケージをにコピーしますローカル倉庫
単一のテストを実行する場合、メソッドを1つずつテストする必要はありません。mvntestコマンドは、すべてのテストケースを実行します。Testで
始まるまたは終わるテストクラスのみが実行されることに注意してください。テストを作成する必要はありません。自分でクラスを作成することをお勧めします。テストクラスをすばやく生成する方法を示す最初の記事を読むことをお勧めします。生成されたテストクラスはすべてTestで終わります。
mvndependency:tree> show.txtは、見やすいように依存関係の出力をファイルにリダイレクトします
詳細なpom.xml
groupId会社のドメイン名が逆になってい
ますartifactId関数コマンド
バージョンバージョン番号
これらの3次元は、(x、y、z)座標を使用して3次元空間内の点を一意に決定するのと同じように、jarパッケージを決定します。
パッケージングパッケージング方法、jar、war、maven-plugin(mavenプラグインの開発)
詳細な範囲
パラメータ | 説明 | 最終的なjarパッケージに入れられますか |
---|---|---|
コンパイル | デフォルトのスコープ | はい |
テスト | テスト使用 | 番号 |
提供 | コンパイルの必要性 | 番号 |
ランタイム | コンパイルには不要、実行時に必要(インターフェースと実装の分離) | はい |
システム | ローカルjarをロードします | 番号 |
以下のように、スコープは指定されていません。これは、スコープがコンパイルされていることを示します。
<dependency>
<groupId>org.mybatis.spring.boot</groupId>
<artifactId>mybatis-spring-boot-starter</artifactId>
<version>1.3.2</version>
</dependency>
テストはテストケースを実行するときに使用され、最終的なjarを入力する必要がないため、表示されるテストフレームワークの範囲は基本的にテストです。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>
ただし、コンパイル時に使用されますが、最終的なjarパッケージには入力されません。
たとえば、TomcatでSpring Bootプロジェクトをwarパッケージとして実行する場合は、最初に次の依存関係を追加する必要があります。
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
<scope>provided</scope>
</dependency>
または、StormクラスターまたはFlinkクラスターで実行するタスクを作成し、最後にStormまたはFlinkの依存関係をprovidedに設定しました。これは、クラスターにこれらの環境用のjarパッケージが既に含まれているためです。
lombokプラグインを使用する場合、lombokのMavenは次の形式であり、コンパイル時にのみ使用されることを示しています。
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.16.6</version>
<scope>provided</scope>
</dependency>
私は次のようにテストクラスを書きました
@Data
public class Test {
private String name;
private int age;
}
逆コンパイル後に生成されるクラスファイルは次のとおりです。これにより、アイデアが検証されます。コンパイル後は、lombokのjarパッケージを使用する必要はありません。
public class Test {
private String name;
private int age;
public Test() {
}
public String getName() {
return this.name;
}
public int getAge() {
return this.age;
}
public void setName(String name) {
this.name = name;
}
public void setAge(int age) {
this.age = age;
}
}
ランタイム。実行時にのみ使用されます。たとえば、プロジェクトにデータベースに対する操作があり、mysql-connector-javaなどの対応するJDBC実装jarパッケージが追加されていない場合、正常にコンパイルでき、エラーは実行時にのみ報告されます。したがって、JDBCによって実装されるjarパッケージのスコープは実行時であり、このjarパッケージは実行時にのみ使用されることを示しています。
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<version>5.1.35</version>
<scope>runtime</scope>
</dependency>
システム、jarをローカルにロードします。サードパーティの会社と協力して、jarパッケージを提供するだけの場合、3つの選択肢があります。
- ローカル倉庫へのmvnインストール
- mvnをプライベートサーバーにデプロイする
- 次のpomフォームのように、jarパッケージパスを指定してローカルにロードします
<dependency>
<groupId>com.tievd.third</groupId>
<artifactId>arcvideo</artifactId>
<version>1.0</version>
<scope>system</scope>
<systemPath>${basedir}/lib/face-api-1.0.jar</systemPath>
</dependency>
前述のように、システムとしてのスコープの依存関係は、最終的なjarパッケージには入力されません。プラグインを構成して最終的なjarパッケージに依存関係を入力する必要があるため、この方法は通常ほとんど使用されません。
依存関係パス
マルチモジュールプロジェクトがあり、依存関係が図に示されているとします。st-webモジュールにst-dal依存関係を導入すると、st-common-lib依存関係も導入されます。これが依存関係の転送です。 、次の表にリストされているように、依存関係プロセス中のスコープの変更がリストされ、列見出しは依存しているモジュールであり、各動作が依存しているモジュールです
コンパイル | テスト | 提供 | ランタイム | |
---|---|---|---|---|
コンパイル | コンパイル | - | - | ランタイム |
テスト | テスト | - | - | テスト |
提供 | 提供 | - | 提供 | 提供 |
ランタイム | ランタイム | - | - | ランタイム |