Section 5.4. Using Binary Dependencies

5.4. Using Binary Dependencies

Imagine yourself on a team of several developers with a project made of several Maven subprojects. When you wish to build the Maven subproject you're working on you have two choices: start by building all its dependencies using the Multiproject plug-in (see Chapter 3) or directly build the said subproject assuming that the dependencies have already been built and are available in your Maven remote repository. The first strategy uses source dependencies (in the sense that you build the dependencies from the sources) and the second strategy uses binary dependencies. The latter is very useful on medium to large projects where building all dependent projects on each developer's machine would take too long. It's also extremely useful when you have several teams, each developing a subset of the full application; each team can concentrate on its own code and release the code as a binary artifact to the other teams. This lab will teach you how to set up a binary dependency strategy.

5.4.1. How do I do that?

You know how to create your own remote repository, how to set up a continuous build, and how to deploy project artifacts. Now you have all of the ingredients necessary for implementing a binary dependencies strategy.

Let's go through the architecture of a binary dependencies build strategy (see Figure 5-7) to see what we need to set up:

• The continuous build runs all the time and builds all subprojects. Whenever it has finished building a project and if the build was successful, it deploys the subproject's artifacts to the Maven remote repository.

• When you build a project, Maven checks the list of its dependencies defined in the project.xml file and verifies if the dependencies are available in the local repository.

• In the case of SNAPSHOT dependencies, Maven will always check if there is a newer snapshot in the remote repository, and will download it in the local repository if this is the case.

Figure 5-7. Building a Maven project using fresh binary dependencies

The key here is to set up a continuous build so that the remote repository is constantly fed with the latest version of all the project's artifacts.

Let's take the example of the QOTD multiproject that you saw in Chapter 3, and let's imagine that you have added a new acceptance test to the acceptance subproject and you'd like to build it. In the previous lab you added a new qotd:deploy goal that deploys all the project's artifacts to the remote repository. You simply need to modify the maven.cruisecontrol.goals property that you used in the previous lab so that CruiseControl calls the qotd:deploy goal and thus deploys fresh artifacts whenever there's a code change:

maven.cruisecontrol.goals = scm:update|clean qotd:deploy

Now, simply type maven qotd:build:

C:\dev\mavenbook\code\qotd\acceptance>maven qotd:build [...]

5.4.2. What just happened?

You have just set up one of the best possible Continuous Integration implementation strategies by using binary dependencies. Imagine the advantages of what you've set up:

• It's fast. Indeed, as a developer you only need to build the project you're working on and you don't need to perform an SCM update on all dependencies and rebuild them all.

• You're always using the latest versions of your project's dependencies, thus ensuring Continuous Integration. As soon as there's a code change, CruiseControl rebuilds the project and republishes the generated artifacts.

• Most importantly, it's fail-safe. Imagine that you're building your project dependencies by hand. You need to perform an SCM update to ensure you're building with the latest source modifications. But doing this is risky. If someone has introduced a change that causes a build failure, you'll get stuck when building the related project and you won't be able to proceed easily with your project's build. However, using this new binary dependency strategy you won't have to bear this: the qotd:deploy goal will deploy its artifacts only if the build has been successful, meaning that all artifacts in the remote repository are guaranteed to have passed the build! So, if one build fails, when you build your project it's going to use the latest dependencies that have successfully passed the build. Of course, this also means that the artifact qualities are only as good as your automated tests are! It really pays to invest in automated testing.