fooこちらのやり方がどうしてもできないような場合にだけ(コメントすらいじれないような状況など)、dfpropでの指定を利用すると良いでしょう。ドキュメント上で値が確認できないので、これらプロパティだけは直接ファイルを開いて目視確認となります。ユニークNoの判定も正しく行われないので、他の環境と同じ値なのかどうかすらドキュメント上ではわからなくなります。通常、環境で分かれるときは環境だけ、言語で分かれるときは言語だけ、二つの要素が入り交じって分かれることはあまりありません。そのためVIEWパートでは(分割ファイルがいくら増えてもいいように)縦に並べて比較できるようにしています。環境だけというのが確定していて、かつ、開発者の画面(ディスプレイ)が横に広い場合は、横並びにして表示することも可能です。言語欄が省略され、横並び表示になります。表示される情報量は同じです。ユニークNoやOverrideのマークは、環境名の横に小さく表示されます。環境が二つか三つくらいと少ない場合に有効です。指定することもできます。それに合わせたドキュメントにすることができます。親Propertiesのリクエスト名を指定します。それぞれのプロパティでオーバーライドしたものかどうかのマークが付きます。}}以下は、mythica_config.propertiesというファイルが、sea_config.propertiesというファイルを継承した場合の例です。いうプロパティをオーバーライドしてることがわかります。階層構造になると、キー名のバッティングで予期せぬ上書き(オーバーライド)で予期せぬトラブルも発生する可能性があります。上書き自体はやりたいことではありますが、それが不意に発生するとデバッグも大変です。把握できれば少しでもトラブル防止につながるはずです。事前に検知できたら一番安心です。生成時にそれをチェックすることができます。すると、暗黙のオーバーライドがあるとDocタスクでPropertiesHTMLを生成する途中でエラーとなります。指定します(コメントの中のどこでもOK)。すると、PropertiesHTMLが正常に生成できます。付いてるのに、オーバーライドになっていない場合も同じくエラーとして検知されます。3Propertiesファイルの中でも、何がオーバーライドで何がそうでないものかが一目瞭然となるため、継承する場合はこの方式でオーバーライドを管理することが推奨されます。それぞれのアプリケーションでたくさん作られてしまうことです。できれば、共通部分は共通プロジェクトで管理して、アプリケーションはそれを参照して、固有のものだけを定義するという形にしたいです。いった仕組み自体は、色々なところで提供されています。いうクラスがあり、複数のPropertiesを継承モデルにして一つのPropertiesのように扱うことができます。(こちらは単なるExampleのクラス)というクラスで共通メッセージを別のPropertiesで管理できるようにしています。階層構造になると、キー名のバッティングで予期せぬ上書き(オーバーライド)で予期せぬトラブルも発生する可能性があります。上書き自体はやりたいことではありますが、それが不意に発生するとデバッグも大変です。把握できれば少しでもトラブル防止につながりますし、チェックを入れてしまえばDocタスクの時点で判明します。アノテーションを付けないとオーバーライドできないというチェックモードが存在します。PropertiesHTMLでやっているチェックと同じです。アプリでも利用できます。コンフィグの仕組みとして利用しています。ExampleDocタスクに含まれてるのはなぜ?PropertiesHTMLを生成する専用のタスクではなく、Docタスクに紛れているのはなぜでしょう?Propertiesって、本番に直結する重要なファイルでありながらも、あまり高い意識を置くものでもないように思えます。いう運用がディベロッパー全員でしっかりと行われるとはなかなか考えにくいです。気付いたらドキュメントができてて必要になったら見る、というくらいが実際の現場にフィットすると考え、Docタスクの一環として含めているのです。DeveloperEnvironmentSetupUpgradeManual。