title: How to use Jenkins job(s) with dependent git repositories and multiple branches
body: <p>We have 2 git repositories, Platform and US (we have other geo-specific ones as well which is why they are split, but they are not necessarily relevant here). US depends on Platform.</p>
  
  <p>We are using git-flow (meaning new features are in their own branches like <code>feature/some-product</code>, <code>develop</code> branch is somewhat more stable and represents QA-ready builds, <code>master</code> branch is stable and for releases). (If a feature has both Platform and US parts, there will be a branch in each with the same name.) We decided that the Jenkins jobs for the features should not run <code>mvn deploy</code> because we don't want to publish them to the snapshot repository and probably shouldn't run <code>mvn install</code> because we don't want a different feature branch to grab it from Jenkins's local repo (this we are less sure about though). We believe they should only make sure everything compiles and that the unit tests pass (<code>mvn verify</code>).</p>
  
  <p><strong>This is where the problem comes in,</strong> because these are separate git repositories and we are not doing anything with the compiled jar (<code>install</code> or <code>deploy</code>),</p>
  
  <ul>
  <li>how can we safely expose the compiled jars from the Platform job to the US without exposing them to other developers or jobs (or is this even a concern is only doing <code>mvn install</code>) or</li>
  <li>how can one Jenkins job build Platform and US for a specific branch together?</li>
  </ul>
  
  <p>If we only have a single actively developed branch (or we were using subversion) this would not be an issue.</p>
  
  <p><strong>Some ideas we have</strong> (and concerns with each)</p>
  
  <ul>
  <li>For feature branches use a different version (e.g., <code>8.1.0-SNAPSHOT-some-product</code>).
  
  <ul>
  <li>This seems like a lot of work for <em>every</em> feature branch.</li>
  <li>It seems like it'd clog up the local repo with "stale" jars, and we would need to worry about purging them.</li>
  </ul></li>
  <li>Somehow use <code>git submodule</code> to checkout Platform's and US's <code>feature/some-product</code> and either use <code>mvn verify --reactor</code> or a simple pom file with the top level projects as modules.
  
  <ul>
  <li>How to make Jenkins add the submodules?</li>
  <li>If the submodules were already there, there would need to be a whole git repo for this, which seems redundant.</li>
  <li><code>--reactor</code> doesn't work always.</li>
  <li>How to supply the pom file?</li>
  </ul></li>
  <li>Just do <code>mvn install</code>.
  
  <ul>
  <li><code>feature/other-thing</code> may only be on US, so after Platform <code>feature/some-product</code> publishes to Jenkins local repository (which may be very different from Platform <code>develop</code>, which US <code>feature/other-thing</code> would be built against normally), it would (We think) cause US <code>feature/other-thing</code> to fail (or pass!) in a false sense (supposing that if it were compiled against Platform <code>develop</code> it could possibly get a different result).</li>
  </ul></li>
  </ul>