2016-10-10 4 views
1

私は、非常に小さなアプリケーション(〜100個のポートレット)を多数管理する小さなチームと連携します。各ポートレットには独自のgitリポジトリがあります。いくつかのコードで、私は今日レビューをしていましたが、誰かが小さな編集をした後、1.88-SNAPSHOTから1.89-SNAPSHOTにpom.xmlのバージョンを更新しました。私はこれが実際にリリースをしたいのかどうかを尋ねるコメントを追加しましたが、これを行うことによる悪影響は実際には分かりません。Mavenスナップショットを常に使用することの結果はどうなりますか?

どうすればよいですか?私はスナップショットがリリースではないと知っていますが、なぜそうではありませんか?スナップショットのみを使用することの結果は何ですか?私はmavenが非スナップショットと同じスナップショットをキャッシュしないことを知っているので、毎回アーティファクトをダウンロードするかもしれませんが、キャッシュは問題ではないとふりましょう。リリース管理の観点からは、たびにSNAPSHOTのバージョンを使用しているだけで、その番号を悪い考えにぶつけてしまうのはなぜですか?

更新: これらのプロジェクトのそれぞれは、チーム外のMavenレポでは使用できないwarファイルになるため、川下のユーザーはいません。

+1

スナップショットはリリース版のようなものですが、利点はありません。スナップショットは開発版であり、いつでも破損して進化する可能性があります。 http://stackoverflow.com/questions/5901378/what-exactly-is-a-maven-snapshot-and-why-do-we-need-itも参照してください。そこの答えがこの問題について議論しています。 – Tunaki

+0

どのようなメリットがありますか?キャッシュとは別に?私の質問は、概念的にSNAPSHOTSのものではありません。私は意図された目的を理解しています。私の質問は、公開用のスナップショットを使用しない場合の具体的なメリットは何ですか? – xdhmoore

+0

SNAPSHOTは開発中のアーティファクトに使用されることが意図されているためです。それらは「リリース」バージョンとして使用することを意図していません。 Mavenはあなたのプロジェクトを多少なりとも動かすことができますが、あなたのプロジェクトに来るMavenを知っているすべての開発者は、何かを理解できず、それはうまくいかないでしょう... – Tunaki

答えて

2

これをやりたいと思っていない主な理由は、全体のMavenのエコシステムは、スナップショットのバージョンが何であるかの具体的な定義に依存しているということです。そして、この定義は、あなたの質問で設定しているものではありません。現在のところ、現在アクティブな開発中のバージョンを表しているに過ぎず、安定版ではありません。その結果は、Mavenの中心に構築されたツールの多くは、デフォルトではこの定義を前提としていることである:

  1. maven-release-pluginは、あなたがリリースされたバージョンとして、スナップショットのバージョンとリリースを準備させません。したがって、あなたのバージョンコントロールで手作業でタグ付けするか、独自のスクリプトを作成する必要があります。これは、これらのライブラリのユーザーがデフォルト設定でこのプラグインを使用できなくなるため、allowTimestampedSnapshotsを設定する必要があることを意味します。ユーザーが設定痛みなしでそれを使用することができなくなりますので、自動的に最新のリリースバージョンに更新するために使用することができます
  2. versions-maven-pluginは、同様に正常に動作しません。
  3. リポジトリマネージャは、Artifactoryやネクサスのように、スナップショットの依存関係をホストするリポジトリの明確な区別を内蔵し、依存関係を解放しています。あなたはネクサス全社共有を使用する場合たとえば、to purge old snapshotsので、これはあなたのために物事を破るように構成することができ...誰かが1.88-SNAPSHOTに依存想像し、それは完全に除去されています。あなたは、時間に戻って、それを再デプロイする必要があります、次の削除まで...また、特定のArtifactory内部リポジトリを設定することができますnot to accept任意のスナップショット、それであなたはそこに展開することはできません。ユーザーは、スナップショットを許可するリポジトリ構成を指すようにリポジトリ構成を追加することを強制されます。
  4. MavenはすべてのMavenプロジェクトが同じセマンティクス(ディレクトリレイアウト、バージョン管理を...)を共有しようとする必要があることを意味し、コンフィギュレーション前大会についてです。あなたのプロジェクトにアクセスする新しい開発者は混乱し、あなたのプロジェクトがどんな形で構築されているのかを理解しようと時間を失います。

最後に、これを行うと、ユーザーに苦しみが増し、1つのことが単純化されることはありません。なぜあなたはおそらく、あなたはそれをやや動作させることができますが、何かが(理由は、会社の方針、または他のいくつかの将来の変更の)破るしようとしたとき、驚いて行動しない...

0

Tunakiは、合理的なポイントの多くを与えましたMavenのベストプラクティスを破って、私はその見解を完全に支持します。あなたは「他の会社の規則」を気にしない場合でも、しかし、理由があります。

  1. あなたはCIをやって(そしてすべての潜在的なリリースとして構築を検討)されていない場合は、どのバージョンを区別する必要があります生産性を高め、テストのためだけの人にしてください。すべてがSNAPSHOTなら、これはやりにくいです。

  2. 誰か(偶然にも)は、1.88-SNAPSHOTを2番目に配置すると、新しい1.88-SNAPSHOTになります(コンクリートのタイムスタンプで利用可能ですが、これは面倒です)。リリースバージョンは2回展開することはできません。

関連する問題