Maven詳細の------mavenバージョン管理
4475 ワード
転載は許可されていますが、出典を明記してください.http://blog.csdn.net/wanghantong/article/38424065、著作権所有
今で言うmavenバージョンはSVNのバージョン制御とは違いますよ!!!
以前、Mavenのバージョンはスナップショットと安定したバージョンに分かれており、スナップショットのバージョンは開発中に使用され、チーム内のコミュニケーション学習に便利であると述べました.安定バージョンというのは、理想的にはプロジェクトが比較的安定した状態に達しており、この安定にはソースコードと構築が安定していることが含まれています.
一、プロジェクトの安定状態をどのように測定しますか?
1.すべての自動化テストはすべて合格しなければならない
2.プロジェクトはスナップショットバージョンの依存関係を構成していません
3.プロジェクトにスナップショットバージョンのプラグインが設定されていません
4.プロジェクトに含まれるコードはすべてバージョン管理システムに提出されました
5.プロジェクトのステータスがOKであることを確認するために、Maven構築をもう一度実行する必要があります.
6.今回の変更をバージョン管理のメインに提出し、ラベルを付けます.
上記の6つの条件を満たしている場合にのみ、このスナップショットバージョンをパブリッシュバージョンに更新できます.
二、開発の過程で、バージョン番号はどのように変更しますか?Mavenには潜在的な約束がありますか?
開発中、jarパッケージをダウンロードすると、1.2.3-beat-4.jarのようなjarがよく見られます.
なんと複雑な名前だろう...ここで、各数字の意味を説明します.
“1 ” : このバージョンの最初の重大バージョンを示します
“2 ” : 重大なバージョンに基づいた2番目のサブバージョンであることを示します.
“3 ” : このサブバージョンの3番目のインクリメンタルを示します
「beat-4」:この増分を表すマイルストーン
1つの図で説明します.
<マスター・バージョン> ------ < 次のバージョン>-------<インクリメンタルバージョン>-------<マイルストーンバージョン>
マスターバージョン:プロジェクトの重大なアーキテクチャ変更を示します struts1 -- struts2
サブバージョン:広範囲の機能の増加と変化を示す Nexus1.5 ---- Nexus1.4
増分バージョン:一般的に重大なバグ修正を表す
マイルストーン・バージョン:あるバージョンのマイルストーンを指します. *.*-alpha-1 *.*-beat-1
ちょっと面倒そうですね.しかし、一般的には、プライマリ・バージョンとセカンダリ・バージョンだけを宣言します.インクリメンタル・バージョンとマイルストーン・バージョンは必ずしもそうではありません.
注意:mavenで約束されたバージョンの順序:
プライマリ・バージョン、セカンダリ・バージョン、インクリメンタル・バージョンの比較は数値ベースであるため、1.5>1.4>1.3>1.2.11>1.2.8
マイルストーンバージョンでは、比較は文字列に基づいているため、1.5>1.4>1.3>1.2.3>1.2.11
三、主幹、分岐、ラベル
上のノートでは主幹とラベルについて言及していますが、主幹、分岐、ラベルをどのように理解しているのでしょうか.
メイン:プロジェクト開発コードの主体は、プロジェクトから現在までアクティブな状態であり、ここからプロジェクトの最新のソースコードとほとんどの変更履歴を得ることができます.
分岐:主幹のある点から分離されたコードコピーは、通常、主幹に影響を及ぼさない前提で、ここで重大なバグ修復や実験的性質の開発を行い、所望の目的を達成すれば、通常、ここの変更を主幹に統合することができる.
ラベル:プロジェクトの安定した状態、すなわち通常のパブリケーションの状態を表すために、メインまたはブランチのポイントの状態を識別します.
この3つの要素は、プロジェクトのバージョン管理を明確に記述することができ、デフォルトの業界標準にもなっています.
四、自動化バージョンのリリース
手動バージョンのリリースが長くなると、自動化されたリリースが可能かどうかを考えます.答えは肯定的です.これは新しいプラグインを導入します.Maven Release Plugin
必要な構成によって、バージョンのリリースを完了できます.
Maven Release Pluginプラグインの概要:
このプラグインには主に3つのターゲットがあります.release:prepare、 release: rollback, release:perform(プラグインターゲットとは何か)は、ブランチ自動化を紹介する際にbranchターゲットも導入されます
①release:prepare リリースの準備をして、次の手順に従います.
1.プロジェクトにコミットされていないコードがあるかどうかを確認する
2.プロジェクトにスナップショットバージョン依存性があるかどうかを確認する
3.ユーザーの入力に従ってスナップショットバージョンをリリースにアップグレードする
4.POMのSCM情報をラベルアドレスに更新する
5.修正後のPOMに基づくmaven構築
6.POM変更の発行
7.ユーザー入力に基づいてコードにラベルを付ける
8.リリースから新しいスナップショットにコードをアップグレード
9.POM変更の発行
release: rollback
release:prepareが実行した操作をロールバックします.POMをrelease:prepareの前の状態に戻し、コミットします.
注意:release:prepareで生成されたラベルは削除されません.ユーザーが手動で削除する必要があります.
release: perform
リリースの実行
release:prepareで生成されたラベルのソースコードに署名し、それに基づいてmvn deployコマンドを実行してコンポーネントを倉庫にパッケージ化して配置します.
注意:プロジェクトのバージョンを公開するには、まず、正しいバージョン管理システム情報を追加する必要があります(これは、Maven Release Pluginがバージョン管理システムのホスト、ラベルなどのアドレスを知ってから、関連する操作を実行する必要があるためです).
②ブランチの自動作成
まず、Maven Release Pluginのbranchターゲットが私たちに何をするのに役立つか見てみましょう.
1.ローカルにコミットされていないコードがあるかどうかを確認
2.ブランチをPOMのバージョンに変更する.例えば:1.1.0-SNAPSHOTを1.1.1-SNAPSHOTに変更する.
3.POMのSCM情報をブランチアドレスに更新する
4.以上の変更をコミット
5.マスターコードをブランチにコピーする
6.ローカルコードをブランチ前のバージョンに戻すように変更します(ユーザーは新しいバージョンを指定できます).
7.ローカル変更のコミット
注意:SCM情報も適切に構成する必要があります.
五、コード安全
コードセキュリティは、中央倉庫からサードパーティ製コンポーネントをダウンロードするときに、これらのファイルの合法性を検証するか、プロジェクトを発表した後、プロジェクトを使用する人も検証するなど、私たちが関心を持っている問題です.
新しいプラグインを導入:Maven GPG Plugin 自動完了署名
Maven GPG Pluginを使用する前に、まずGPGが利用可能であることを確認し、POMでプラグインを構成すればよい.
pom.xml
次に、一般的なMavenコマンドを使用してプロジェクトコンポーネントに署名し、パブリッシュします.
注意:
1. -Dgpg.passphraseパラメータが指定されていない場合、実行時にパスワードの入力が要求されます.
自分を爱する最も良い方法は努力して奋闘して自分を优秀になって、もしあなたが更に退廃するならば、気がふさいで知己がなくて、本当の爱が见つからないで、あなた自身さえ自分を爱しないため、また他の人があなたを爱することを妄想しますか?あなたは何か爱する価値がありますか?往々にして一人で気にするのはお金ではなく奮闘の心ですね.悟りましょう!これ以上堕落するな!
今で言うmavenバージョンはSVNのバージョン制御とは違いますよ!!!
以前、Mavenのバージョンはスナップショットと安定したバージョンに分かれており、スナップショットのバージョンは開発中に使用され、チーム内のコミュニケーション学習に便利であると述べました.安定バージョンというのは、理想的にはプロジェクトが比較的安定した状態に達しており、この安定にはソースコードと構築が安定していることが含まれています.
一、プロジェクトの安定状態をどのように測定しますか?
1.すべての自動化テストはすべて合格しなければならない
2.プロジェクトはスナップショットバージョンの依存関係を構成していません
3.プロジェクトにスナップショットバージョンのプラグインが設定されていません
4.プロジェクトに含まれるコードはすべてバージョン管理システムに提出されました
5.プロジェクトのステータスがOKであることを確認するために、Maven構築をもう一度実行する必要があります.
6.今回の変更をバージョン管理のメインに提出し、ラベルを付けます.
上記の6つの条件を満たしている場合にのみ、このスナップショットバージョンをパブリッシュバージョンに更新できます.
二、開発の過程で、バージョン番号はどのように変更しますか?Mavenには潜在的な約束がありますか?
開発中、jarパッケージをダウンロードすると、1.2.3-beat-4.jarのようなjarがよく見られます.
なんと複雑な名前だろう...ここで、各数字の意味を説明します.
“1 ” : このバージョンの最初の重大バージョンを示します
“2 ” : 重大なバージョンに基づいた2番目のサブバージョンであることを示します.
“3 ” : このサブバージョンの3番目のインクリメンタルを示します
「beat-4」:この増分を表すマイルストーン
1つの図で説明します.
<マスター・バージョン> ------ < 次のバージョン>-------<インクリメンタルバージョン>-------<マイルストーンバージョン>
マスターバージョン:プロジェクトの重大なアーキテクチャ変更を示します struts1 -- struts2
サブバージョン:広範囲の機能の増加と変化を示す Nexus1.5 ---- Nexus1.4
増分バージョン:一般的に重大なバグ修正を表す
マイルストーン・バージョン:あるバージョンのマイルストーンを指します. *.*-alpha-1 *.*-beat-1
ちょっと面倒そうですね.しかし、一般的には、プライマリ・バージョンとセカンダリ・バージョンだけを宣言します.インクリメンタル・バージョンとマイルストーン・バージョンは必ずしもそうではありません.
注意:mavenで約束されたバージョンの順序:
プライマリ・バージョン、セカンダリ・バージョン、インクリメンタル・バージョンの比較は数値ベースであるため、1.5>1.4>1.3>1.2.11>1.2.8
マイルストーンバージョンでは、比較は文字列に基づいているため、1.5>1.4>1.3>1.2.3>1.2.11
三、主幹、分岐、ラベル
上のノートでは主幹とラベルについて言及していますが、主幹、分岐、ラベルをどのように理解しているのでしょうか.
メイン:プロジェクト開発コードの主体は、プロジェクトから現在までアクティブな状態であり、ここからプロジェクトの最新のソースコードとほとんどの変更履歴を得ることができます.
分岐:主幹のある点から分離されたコードコピーは、通常、主幹に影響を及ぼさない前提で、ここで重大なバグ修復や実験的性質の開発を行い、所望の目的を達成すれば、通常、ここの変更を主幹に統合することができる.
ラベル:プロジェクトの安定した状態、すなわち通常のパブリケーションの状態を表すために、メインまたはブランチのポイントの状態を識別します.
この3つの要素は、プロジェクトのバージョン管理を明確に記述することができ、デフォルトの業界標準にもなっています.
四、自動化バージョンのリリース
手動バージョンのリリースが長くなると、自動化されたリリースが可能かどうかを考えます.答えは肯定的です.これは新しいプラグインを導入します.Maven Release Plugin
必要な構成によって、バージョンのリリースを完了できます.
Maven Release Pluginプラグインの概要:
このプラグインには主に3つのターゲットがあります.release:prepare、 release: rollback, release:perform(プラグインターゲットとは何か)は、ブランチ自動化を紹介する際にbranchターゲットも導入されます
①release:prepare リリースの準備をして、次の手順に従います.
1.プロジェクトにコミットされていないコードがあるかどうかを確認する
2.プロジェクトにスナップショットバージョン依存性があるかどうかを確認する
3.ユーザーの入力に従ってスナップショットバージョンをリリースにアップグレードする
4.POMのSCM情報をラベルアドレスに更新する
5.修正後のPOMに基づくmaven構築
6.POM変更の発行
7.ユーザー入力に基づいてコードにラベルを付ける
8.リリースから新しいスナップショットにコードをアップグレード
9.POM変更の発行
release: rollback
release:prepareが実行した操作をロールバックします.POMをrelease:prepareの前の状態に戻し、コミットします.
注意:release:prepareで生成されたラベルは削除されません.ユーザーが手動で削除する必要があります.
release: perform
リリースの実行
release:prepareで生成されたラベルのソースコードに署名し、それに基づいてmvn deployコマンドを実行してコンポーネントを倉庫にパッケージ化して配置します.
注意:プロジェクトのバージョンを公開するには、まず、正しいバージョン管理システム情報を追加する必要があります(これは、Maven Release Pluginがバージョン管理システムのホスト、ラベルなどのアドレスを知ってから、関連する操作を実行する必要があるためです).
②ブランチの自動作成
まず、Maven Release Pluginのbranchターゲットが私たちに何をするのに役立つか見てみましょう.
1.ローカルにコミットされていないコードがあるかどうかを確認
2.ブランチをPOMのバージョンに変更する.例えば:1.1.0-SNAPSHOTを1.1.1-SNAPSHOTに変更する.
3.POMのSCM情報をブランチアドレスに更新する
4.以上の変更をコミット
5.マスターコードをブランチにコピーする
6.ローカルコードをブランチ前のバージョンに戻すように変更します(ユーザーは新しいバージョンを指定できます).
7.ローカル変更のコミット
注意:SCM情報も適切に構成する必要があります.
五、コード安全
コードセキュリティは、中央倉庫からサードパーティ製コンポーネントをダウンロードするときに、これらのファイルの合法性を検証するか、プロジェクトを発表した後、プロジェクトを使用する人も検証するなど、私たちが関心を持っている問題です.
新しいプラグインを導入:Maven GPG Plugin 自動完了署名
Maven GPG Pluginを使用する前に、まずGPGが利用可能であることを確認し、POMでプラグインを構成すればよい.
pom.xml
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-gpg-plugin</artifactId>
<version>1.0</version>
<executions>
<execution>
<id>sign-artifacts</id>
<phase>verify</phase>
<goals>
<goal>sign</goal>
</goals>
</execution>
</executions>
</plugin>次に、一般的なMavenコマンドを使用してプロジェクトコンポーネントに署名し、パブリッシュします.
$mvn clean deploy -Dgpg.passphrase=****注意:
1. -Dgpg.passphraseパラメータが指定されていない場合、実行時にパスワードの入力が要求されます.
自分を爱する最も良い方法は努力して奋闘して自分を优秀になって、もしあなたが更に退廃するならば、気がふさいで知己がなくて、本当の爱が见つからないで、あなた自身さえ自分を爱しないため、また他の人があなたを爱することを妄想しますか?あなたは何か爱する価値がありますか?往々にして一人で気にするのはお金ではなく奮闘の心ですね.悟りましょう!これ以上堕落するな!