デプロイスクリプトのデプロイメントディレクトリ、実行するポート、使用するデータベースとWebサービスなど、開発者のサンドボックス設定用のプロジェクトで、profiles.xmlとさまざまな{username}.propertiesを使用するプロジェクトをいくつか見てきました。 、など。Maven 3でprofiles.xmlのサポートが削除されたため、この方法に完全に疑問を投げかけました。だから私はいくつかの質問があります：
あなたが言ったように、Maven3は外部profiles.xmlファイルのサポートのみを削除しました。プロファイルは、settings.xmlと、いつものようにpom.xmlで引き続き使用できます。現在外部profiles.xmlファイルを持っているプロジェクトは、それらの構成をローカルユーザーのsettings.xmlファイルに移動する必要があります。
1）環境固有の値を管理するためのプロファイル構成よりも優れたメカニズムは実際にはありません。
2）scm内のユーザープロパティファイルは、所有しているコンテンツと、その情報が他のユーザーに機密情報であるかどうかによって異なります。ソースツリーを正しく構成すれば、SCMに保存するのに問題はありません。
3）これまで私が取り組んできた他のプロジェクトでは、タグ、トランク、ブランチの横に、構成ファイルのテンプレートを含むベースディレクトリを持つ構成と呼ばれるSVNを含む別のディレクトリを保持していました。開発者フォルダとサーバーディレクトリのように見えます。開発者は、ベースディレクトリから、構成ファイルの独自のコピーを持つ開発者ディレクトリの下に独自のディレクトリを作成/分岐します。これにより、変更を基本バージョンにマージし、「それらの」構成を更新することができました。これにより、これらのサービスURLの変更の多くが解決され、時間どおりに実行できるようになります。
4）手がかりではありません。彼らが削除したかったMaven1からのホールドオーバーである可能性があります。
ああ、Maven 2.2と3.0では、settings.xmlで値を暗号化できることを忘れないでください。
これを達成するために、プロファイルよりも優れたメカニズムはありますか？
いいえ、プロファイルはまだこれに最適です。
そうでない場合は、{username} .propertiesがscmに属していると思いますか？たとえば、サービスURLが変更されたときに、すべての開発者のプロパティを更新するのを忘れることがあります。
私は通常、ユーザー固有のプロパティをファイル~/.m2/settings.xml内の共通のプロパティに配置しpom.xmlます。
これらのプロパティファイルをscmに含めることは悪い考えではありませんが、開発者のサンドボックス間で共通の設定に何らかのプロファイルの継承があるべきですか？どうすればそれができますか？
継承の恩恵を受けたい場合は、mavenを使用することをお勧めします<properties>。
ちなみに、ApacheがMaven 3でprofiles.xmlのサポートを削除した理由を知っていますか？
のサポートによりprofiles.xml、Mavenの内部が複雑になり、テストが困難になりました。また、ほとんどの場合、使用settings.xmlは許容できる代替手段であるため、profiles.xml削除されました。次のスレッド（特にJazonのメッセージ）を参照してください。