Section 3.4. Sharing Artifacts Through the Local Maven Repository | Maven: A Developers Notebook (Developers Notebooks)

3.4. Sharing Artifacts Through the Local Maven Repository

Figure 3-1 illustrates the dependencies between the subproject, and from this diagram, you can see that the web subproject depends upon the core subproject. How do you share artifacts between projects in Maven?

3.4.1. How do I do that?

You do this through the local Maven repository, which was introduced in Section 1.1. The core build will publish its JAR to the repository and the web build will define a dependency on the core JAR.

To refresh your memory, your local repository resides in ~/.maven/repository on Unix, or %USERPROFILE%\.maven\repository on Windows. Publishing a JAR to your local repository is as simple as executing the jar:install goal:

C:\dev\mavenbook\code\qotd\core>maven jar:install  _ _  _ _ |  \/  |_ _ _Apache_ _ _ _ _ | |\/| / _` \ V / -_) ' \  ~ intelligent projects ~ |_|  |_\_ _,_|\_/\_ _ _|_||_|  v. 1.0.2    build:start:    java:prepare-filesystem:     [mkdir] Created dir: C:\dev\mavenbook\code\qotd\core\target\classes    java:compile:     [echo] Compiling to C:\dev\mavenbook\code\qotd\core/target/classes     [javac] Compiling 1 source file to C:\dev\mavenbook\code\qotd\core\target\classes    java:jar-resources:    test:prepare-filesystem:     [mkdir] Created dir: C:\dev\mavenbook\code\qotd\core\target\test-classes     [mkdir] Created dir: C:\dev\mavenbook\code\qotd\core\target\test-reports    test:test-resources:    test:compile:     [javac] Compiling 1 source file to C:\dev\mavenbook\code\qotd\core\target\test-classes    test:test:     [junit] Testsuite: mdn.qotd.core.QuoteGeneratorTest     [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 4,226 sec     [junit]     [junit] Testcase: testGenerate took 3,926 sec    jar:jar:     [jar] Building jar: C:\dev\mavenbook\code\qotd\core\target\qotd-core-1.0.jar Copying: from 'C:\dev\mavenbook\code\qotd\core\target\qotd-core-1.0.jar' to: 'C:\Documents and Settings\Vincent Massol\.maven\repository\mdn\jars\qotd-core-1.0.jar' Copying: from 'C:\dev\mavenbook\code\qotd\core\project.xml' to: 'C:\Documents and Settings\Vincent Massol\.maven\repository\mdn\poms\qotd-core-1.0.pom' BUILD SUCCESSFUL Total time: 10 seconds

The core JAR is now located in [MAVEN_REPO]/mdn/jars/qotd-core-1.0.jar. The jar:install depends on the jar:jar goal which, in turn, triggers the java:compile and test:test goals.

Note: Maven is very fond of unit testing. Every time you try to create a JAR file or deploy a site, Maven will run those unit tests.

Now that qotd-core-1.0.jar is installed in your local Maven repository, how do you reference it from another project? To reference the core JAR from another Maven project, add the following dependency in project.xml:

    <dependency>       <groupId>mdn</groupId>       <artifactId>qotd-core</artifactId>       <version>${pom.currentVersion}</version>     </dependency>

Note that you are using the expression ${pom.currentVersion}, which refers to the value of the currentVersion element (defined in common/project.xml with a value of 1.0). In this manner you avoid hardcoding it so that you don't need to modify the version element whenever the project's version is modified.

The current version of QOTD is defined for all subprojects in common/project.xml. Referencing ${pom.currentVersion} in subprojects that do not inherit the same currentVersion element would produce errors. This technique requires all subprojects to be on the same version, which is generally the case for multiprojects. All subprojects should be released together in a multiproject. If some subprojects should be released individually, consider separating them from the multiproject.

3.4.2. What just happened?

Maven enforces the decoupling of projects by sharing artifacts through the local repository. Instead of projects depending on each other directly, each project depends on the contents of the local repository. The web subproject simply depends upon the qotd-core artifact in the local repository. Maven projects do not relate to each other through relative paths or environment variables, as this creates brittle build systems and steep learning curves for new developers. Projects simply depend on artifacts from other projects.

We remember the old times when projects such as Jakarta Taglibs were using Ant, and projects were tightly coupled with one another through the use of relative paths (e.g., ../../otherproject/target/dist/otherproject.jar). The only way to build Jakarta Taglibs was to check out a few sibling projects, download a few JAR files, and configure a user-specific configuration filebuild.properties-samplewhich was stored in source control. All of this made build maintenance a nightmare, as modifying one project's build had repercussions on other projects. The more complex an Ant build became, and the more interdependent projects became, the more build maintenance came to resemble an endless game of whack-a-mole. No more of this futility with Maven!