Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I'm not sure I understand your problem so let me try to rephrase it.</p> <p>You have 4 projects, A, B, C and X. You have A, B, and C defined as sub-projects of X When you build project X you want to include the tar.gz files for projects A, B and C.</p> <p>The problem is that you want to build A only if required, and download it from the project repository if it is already present?</p> <p>Assuming I understand the problem correctly, I'm still not clear how you expect the children to be conditionally built. If X declares the others as modules Maven will always build them along with the parent. If X declares the others as dependencies they will only ever be treated as dependencies, so the build will fail unless the artifacts exist in the repository (i.e. you've already built them).</p> <hr> <p>If you want to be able to exercise flexibility over the build, I'd recommend separating the responsibilities of assembly and aggregator into different projects. </p> <p>The aggregator simply declares the projects as modules so you can conveniently build all the projects in one command.</p> <p>The assembly project (your project X) declares dependencies on projects A, B and C. When you build project X it is required that the others have already been built, but if built in the aggregator, the reactor will have built them first. Whereas if you build it standalone, you know the others are up to date.</p> <hr> <p>Some additional points on Maven usage that should clarify this approach.</p> <p>The Maven repository is a record of all the artifacts you've developed. You <em>don't need to clear the local repository between builds</em>. It is intended to act as a repository of all the artifacts. So if you install project A, that is the version that will always be used (unless and until you rebuild project A).</p> <p>If you <em>do</em> have to clear the local repository, you should <em>deploy</em> your artifacts to a remote repository (see the relevant section of the <a href="http://www.sonatype.com/books/nexus-book/reference/" rel="nofollow noreferrer">Nexus book</a> for guidance on getting started) so they can be incorporated into your build for project X even if the local repository is cleared.</p> <p>So the workflow for building the projects is:</p> <ol> <li>Run mvn install on the aggregator project or the relevant project (A,B, or C).</li> <li>Projects are installed to the local repository.</li> <li>Don't clear the local repository!</li> <li>Run mvn install on project X, Maven will retrieve the dependencies from the repository and package them into your assembly.</li> </ol> <p>If you use mvn deploy, the same principles apply, but because the artifacts are in the remote repository you have freedom to clear the local repository.</p> <p>To emphasise my earlier points:</p> <ul> <li>There is no mechanism to conditionally build modules. They either build or they don't (however some steps of the build might be skipped if they are not needed, e.g. compilation might have already been done in a previous build)</li> <li>There is no need to purge the local repository (and if you do, you should have the modules deployed to a remote repository so they can be retrieved).</li> </ul>
    singulars
    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. This table or related slice is empty.
    1. This table or related slice is empty.
    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