Maven optionalのキーワードの徹底的な図解を詳しく説明します。
前に書く
本来は「Spring Boot Starterをカスタマイズする方法」を書きたいですが、Starterのいくつかのデザイン理念とその中のポイントをよりよく理解するために、事前にいくつかの細部の内容を単独で抽出して説明します。
Maven pom.xmlでは、依存項に次のようなコードが見られます。
optionalキーワードの奥秘
古い決まりです。図を書いて問題を説明します。
project Cはproject Aからのクラス(Optional Feature AClass)とproject Bのクラス(Optional Feature BRAss)を2つ使用していますので、プロジェクトCがpackage AとpackageBに依存していない場合、コンパイルは失敗します。
project Dはproject Cに依存していますが、クラス(Optional Feature AClass)とクラス(Optional Feature BRAss)はオプションの特性ですので、最終的なwar/ejb packageは不要な依存を含まないように、
プロジェクトDが確かにプロジェクトCのOptional Feature AClassを使う必要があるとしたら、どうすればいいですか?私たちはproject Dのpom.xmlに明示的に声明を追加する必要があります。次の図を見てください。
Project DはProject AのOptional Feature AClassを使用する必要があるので、Project Dのpom.xmlファイルに明示的にProject Aへの依存を追加する必要があります。
これでよく分かります。なぜMavenはoptionalキーワードを設計したのですか?データベースの恒久化に関するプロジェクト(Project C)を仮定して、より多くのタイプのデータベースの恒久化設計を適応するために、Mysql恒久化設計(Project A)とOracleの恒久化設計(Project B)が必要となります。mysqlドライバを導入したり、oracleドライバを導入したりすることはできないでしょう。だから、我々は明示的に指定します。これです。
実際の判例
spring-boot-actuat or pom.xmlファイルには、20以上の依存がoptionalです。
Spring Bootは必要ない依存をあなたの最終的なjar packageにパッケージ化することは不可能ですので、spring boot actuatのプロジェクトで最終的に生成したjar packageにはこの20以上の依存jarは含まれません。どちらを使うなら、明示的にあなたのプロジェクトに参加すればいいです。
次の文章では、Spring Boot Starterをカスタマイズするのもこの策略です。starterは特定の機能を含んで他のプロジェクトのために使うので、本文のProject Cのようなキャラクターです。ここでoptionalの奥秘を理解しましたか?
逆方向への適用
もしProject Cに導入された依存が
ここに来て、あなたが今後設計機能に依存する時、どのような設計依存関係があるかを知るべきです。ここではオプティナルの形式をおすすめします。簡単に言えば、あなたのデザインはどんな料理に依存していますか?
魂の問い詰め子供靴プロジェクトグループ用の構築ツールがたくさんありますが、Graadleではどのように表示されていますか? カスタムstarterですが、公式標準starterの構造はどうなっていますか? 以上が本文の全部です。皆さんの勉強に役に立つように、私たちを応援してください。
本来は「Spring Boot Starterをカスタマイズする方法」を書きたいですが、Starterのいくつかのデザイン理念とその中のポイントをよりよく理解するために、事前にいくつかの細部の内容を単独で抽出して説明します。
Maven pom.xmlでは、依存項に次のようなコードが見られます。
<dependency>
<groupId>sample.ProjectA</groupId>
<artifactId>Project-A</artifactId>
<version>1.0</version>
<scope>compile</scope>
<optional>true</optional>
</dependency>
ここの<optional>true</optional>
はどういう意味ですか?optionalキーワードの奥秘
古い決まりです。図を書いて問題を説明します。
project Cはproject Aからのクラス(Optional Feature AClass)とproject Bのクラス(Optional Feature BRAss)を2つ使用していますので、プロジェクトCがpackage AとpackageBに依存していない場合、コンパイルは失敗します。
project Dはproject Cに依存していますが、クラス(Optional Feature AClass)とクラス(Optional Feature BRAss)はオプションの特性ですので、最終的なwar/ejb packageは不要な依存を含まないように、
<optional>
を使って現在の依存を宣言します。デフォルトでは他のプロジェクトに継承されません。他のクラスに継承されないように)プロジェクトDが確かにプロジェクトCのOptional Feature AClassを使う必要があるとしたら、どうすればいいですか?私たちはproject Dのpom.xmlに明示的に声明を追加する必要があります。次の図を見てください。
Project DはProject AのOptional Feature AClassを使用する必要があるので、Project Dのpom.xmlファイルに明示的にProject Aへの依存を追加する必要があります。
これでよく分かります。なぜMavenはoptionalキーワードを設計したのですか?データベースの恒久化に関するプロジェクト(Project C)を仮定して、より多くのタイプのデータベースの恒久化設計を適応するために、Mysql恒久化設計(Project A)とOracleの恒久化設計(Project B)が必要となります。mysqlドライバを導入したり、oracleドライバを導入したりすることはできないでしょう。だから、我々は明示的に指定します。これです。
実際の判例
spring-boot-actuat or pom.xmlファイルには、20以上の依存がoptionalです。
Spring Bootは必要ない依存をあなたの最終的なjar packageにパッケージ化することは不可能ですので、spring boot actuatのプロジェクトで最終的に生成したjar packageにはこの20以上の依存jarは含まれません。どちらを使うなら、明示的にあなたのプロジェクトに参加すればいいです。
次の文章では、Spring Boot Starterをカスタマイズするのもこの策略です。starterは特定の機能を含んで他のプロジェクトのために使うので、本文のProject Cのようなキャラクターです。ここでoptionalの奥秘を理解しましたか?
逆方向への適用
もしProject Cに導入された依存が
<optional>true</optional>
に加わらなかったら、Project DはまたProject Cに依存する必要がありますが、Project Aのクラスだけにしたらどうなりますか?Mavenにも解決方法があります。exclusionのキーワードを使って、多く言わないと、前のコードが分かります。
<dependencies>
<dependency>
<groupId>top.dayarch.demo</groupId>
<artifactId>Project-C</artifactId>
<exclusions>
<exclusion>
<groupId>top.dayarch.demo</groupId>
<artifactId>Project-B</artifactId>
</exclusion>
</exclusions>
</dependency>
</dependencies>
締め括りをつけるここに来て、あなたが今後設計機能に依存する時、どのような設計依存関係があるかを知るべきです。ここではオプティナルの形式をおすすめします。簡単に言えば、あなたのデザインはどんな料理に依存していますか?
魂の問い詰め