Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>This is really just a Maven/JSF question. Jenkins does not really enter the equation, and neither does CloudBees (note we [cloudbees] also support Subversion hosted repositories which may or may not fit your project structure better... in any case GIT is IMHO “better” so I would go for GIT over Subversion if it was me)</p> <p>You have three options really.</p> <ol> <li><p>Keep the XHTML in a separate GIT repository</p></li> <li><p>Keep everything in one repository.</p></li> <li><p>A kind of mix of 1 &amp; 2</p></li> </ol> <h2>Option 1</h2> <p>This will drive you down the road of GIT submodules... that is the one case where I would favour Subversion over GIT... and no I don't mean that <code>svn:externals</code> is better that GIT, more that Subversion allows you to check out a portion of the repository, so the UI team could just check out the sub-path where the XHTML files live, IOW</p> <pre><code>$ svn co https://svn-user1530669.forge.cloudbees.com/jsf-app/trunk/web-module/src/main/webapp web-content $ cd web-content </code></pre> <p>would work for the UI team and</p> <pre><code>$ svn co https://svn-user1530669.forge.cloudbees.com/jsf-app/trunk jsf-app $ cd jsf-app $ mvn package </code></pre> <p>will work for the Java developers.</p> <p>To achieve the same with GIT requires the use of sub-modules, so you would have one sub-module at <code>web-module/src/main/webapp</code> in the jsf-app GIT repo.</p> <p>Where this becomes a pain is when the Java developers need to make tweaks to the XHTML files as well, depending on the IDE it can be tricky to get the commits in the submodule to take correctly. Also you now do not have a single revision to track, the two repos can move independently... which can degrade some of the features of GIT.</p> <p>When you want to use the Maven release plugin (and you should want to) Submodules will prevent you, as both the idea of tagging submodules is not currently supported by the release plugin, and there is that two separate repos to track issue again.</p> <h2>Option 2</h2> <p>This really is the better option... even though it is doing exactly what you said you didn't want to do.</p> <p>The trick here is to make the UI developer's life easier.</p> <p>You should set up a nice Maven profile with a default goal which ends up running the web application with e.g. jetty:run see for example <a href="https://github.com/tobar-segais/tobar-segais/blob/master/pom.xml#L193" rel="nofollow">This pom profile</a> If you check out that project and just run</p> <pre><code>$ mvn -Pdemo </code></pre> <p>It will fire up the web application from the sub-module having built all the dependent modules.</p> <p>Using this approach means that the UI guys can also test the UI changes integrated into the JSF app reducing the load on the Java guys.</p> <h2>Option 3</h2> <p>This is a kind of mix, you have separate GIT modules for the XHTML and the Java, but they are valid Maven projects.</p> <p>You can achieve this in two ways...</p> <ul> <li><p>Have the XHTML module be a <code>&lt;packaging&gt;war&lt;/packaging&gt;</code> which is extracted into the Java web-app using Maven War Overlays</p></li> <li><p>Have the XHTML module be a <code>&lt;packaging&gt;war&lt;/packaging&gt;</code> which has the Java dependencies pulled in directly.</p></li> </ul> <p>The first has the advantage that the Java developers can work with the Java code quickly, but the side-effect is fixing XHTML is tricky e.g. data-binding attributes</p> <p>The second makes tweaking the Java harder (have to keep running <code>mvn install</code>), the UI guys have to pull down the Java .JARs from the remote Maven repo if they want to spin up the Maven packaging, and hence you may expose some of your java internals to the UI guys.</p> <h2>TL;DR</h2> <p>Personally, unless <em>keeping things secret</em> from the UI guys is something that is important, I would pick <strong>Option 2</strong></p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload