6

Ant プロジェクトを Maven プロジェクトに変換しています。このプロジェクトは、非常に頻繁に (通常は 1 日に 8 ～ 10 回) リリースされるため、私が通常変換したプロジェクトとは異なります。

リリースとは、結果の jar がパッケージ化され、運用環境に含まれていることを意味します。このプロジェクトはリーフプロジェクトであるため、API を発行せず、使用するだけです。また、多くても他の 2 つのプロジェクトのランタイム依存関係です。

次のようなバージョン管理スキームが必要です。

  • 番号には意味がないため、開発者がプロ​​ジェクトに割り当てるバージョン番号について考える必要がなく、簡単に展開できます。
  • このプロジェクトの最新バージョンを依存関係として含めるのは簡単で、依存関係のバージョンを頻繁に上げる必要はありません。

他のプロジェクトで使用して-SNAPSHOTいる と競合するため、依存関係のバージョンはおそらく ではありませんが、提案は受け付けています。maven-release-plugin

4

1 に答える 1

5

実際には、x-SNAPSHOTバージョンを使用して、引き続きmaven-release-plugin を使用できます。mvn release:preparebeforeを使用mvn release:performしてリリースを準備し、poms のバージョンをx-SNAPSHOT新しいバージョンに変更します (使用するバージョンを求めるプロンプトが表示されます)。との簡単な概要については、このmaven-release-plugin の概要をご覧ください。release:preparerelease:perform

次に、依存関係のバージョンを常に更新せずに最新バージョンを含めるには、次のスニペットのように、Junit 3.8 ～ Junit 4.0 の範囲を指定する依存関係範囲を使用できます。

<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <version>[3.8,4.0)</version>
  <scope>test</scope>
</dependency>

コンマの前後のバージョンは必須ではなく、+/- 無限大を意味します。たとえば、[4.0,)は 4.0 以降の任意のバージョンを意味します。

個人的には、ビルドの再現性の問題につながり、ビルドがより脆弱になる可能性があるため、依存関係の範囲をあまり使用したくありません。

しかし、それらを使用する正当な理由があるかもしれません。

于 2009-10-06T09:50:16.543 に答える