これは実際には Maven/JSF に関する質問です。Jenkinsは実際には方程式に入らず、CloudBeesもそうではありません(私たち[cloudbees]は、プロジェクト構造により適しているかどうかに関係なく、Subversionがホストするリポジトリもサポートしていることに注意してください...いずれにせよ、GITは私見で「より良い」ので、私はそれが私だったらSubversion上のGIT)
実際には 3 つのオプションがあります。
XHTML を別の GIT リポジトリに保持する
すべてを 1 つのリポジトリに保管します。
1と2の混合の一種
オプション1
svn:externals
これにより、GITサブモジュールの道をたどることになります...これは、私がGITよりもSubversionを好む1つのケースです...そして、GITよりも優れているという意味ではありません。UI チームは、XHTML ファイルが存在するサブパス、IOW をチェックアウトするだけで済みます。
$ svn co https://svn-user1530669.forge.cloudbees.com/jsf-app/trunk/web-module/src/main/webapp web-content
$ cd web-content
UIチームのために働き、
$ svn co https://svn-user1530669.forge.cloudbees.com/jsf-app/trunk jsf-app
$ cd jsf-app
$ mvn package
Java 開発者向けです。
GIT で同じことを実現するには、サブモジュールを使用する必要があるためweb-module/src/main/webapp
、jsf-app GIT リポジトリに 1 つのサブモジュールを配置します。
これが問題になるのは、Java 開発者が XHTML ファイルにも微調整を加える必要がある場合です。IDE によっては、サブモジュールのコミットを正しく取得するのが難しい場合があります。また、追跡する単一のリビジョンがないため、2 つのリポジトリを個別に移動できます...これにより、GIT の機能の一部が低下する可能性があります。
Maven リリース プラグインを使用する場合 (および使用する必要がある場合) は、サブモジュールにタグを付けるというアイデアが現在リリース プラグインでサポートされておらず、問題を再度追跡するための 2 つの個別のリポジトリがあるため、サブモジュールが妨げになります。
オプション 2
これは実際にはより良いオプションです...あなたがやりたくないと言ったことを正確に実行しているにもかかわらず.
ここでの秘訣は、UI 開発者の作業を楽にすることです。
たとえば jetty:run を使用して Web アプリケーションを実行するデフォルトの目標を持つ素敵な Maven プロファイルを設定する必要があります。たとえば、この pom プロファイルを参照してください。そのプロジェクトをチェックアウトして実行するだけの場合
$ mvn -Pdemo
すべての依存モジュールをビルドしたサブモジュールから Web アプリケーションを起動します。
このアプローチを使用すると、UI 担当者も JSF アプリに統合された UI の変更をテストできるようになり、Java 担当者の負荷が軽減されます。
オプション 3
これは一種の組み合わせです。XHTML と Java 用に個別の GIT モジュールがありますが、これらは有効な Maven プロジェクトです。
これは 2 つの方法で実現できます...
前者には、Java 開発者が Java コードをすばやく操作できるという利点がありますが、副作用として、データバインディング属性などの XHTML の修正が難しくなります。
2 つ目は、Java の微調整を難しくします (実行し続ける必要がmvn install
あります)。UI 担当者は、Maven パッケージをスピンアップしたい場合、リモートの Maven リポジトリから Java .JAR をプルダウンする必要があるため、Java 内部の一部を公開する可能性があります。 UIの人たちへ。
TL;DR
個人的には、UI担当者に秘密にしておくことが重要でない限り、オプション 2を選択します。