Managing dependencies with Maven

Content:

Maven abstract.

Tunning your Maven proyect

Maven standard folders

Managing dependencies with Maven

Adding a nature in Eclipse

Maven profiles inheritance

How does Maven work?

Maven uses repositories for searching any dependency you declare in POM.xml, there are strictly only two types of repositories: local and remote.

The local repository (today's theme) refers to a copy on your own installation that is a cache of the remote downloads, and also contains the temporary build artifacts that you have not yet released. (As said in Maven website).

When working with Eclipse, there are two levels for local repositories. Maven builds one repository over your workspace, therefore, if you have any dependency loaded as project in your workspace, it will be taken previous to any other equally-versioned jar.

The second level for local repositories is your personal space in disk. Maven automatically configures a repository inside your user directory (.m2 for Maven 2), and it is used for synchronizing all your projects, Eclipsoid or not.

In the higher step of this ladder, remote repositories. They could be a server in our own intranet, or one of the mirrors proposed by Maven for downloading its huge library.


Let's do a practice example:

Step one: Creation of secundary project.

Open an instance of SpringSource, configure it for working in the brand-new workspace "workspace_a". It doesn't matter the real path, it only matters that it is new and clean.

Create a "Maven Project",

We have reached the next window using only the "Windows Brain" (next.. next.. next..), until we are prompted for a "Group Id", "Artifact Id" and "Version".

Group Id: Sort of organizational name or hierarchy. It is a good idea that use your domain for all your packets, it could be at the same time your namespace and a good clue for where to locate more of your business.

Artifact Id: Name for this package.

Version: Initial version. SNAPSHOT tells Maven to look for more recent versions in their configured repositories. 

If an App.java was created, we wont need anymore for this part of the example.

Try to Run as.. Maven Install.

With this command, you are telling Maven to compile, run tests, and, if succeeded, deploy in local Maven repository to share with other projects.

Now close your SpringSource IDE if you can't afford having two IDEs opened.


Step two: Creation of main project.

Let's do it quickly and painless. As we did in other article, New Project -> Spring Template -> MVC Spring Project (or something similar, I'm not reading it right now :P). I call it "war", why not.

We won't run this new project, because we don't need to. What we only want is being able to compile the code.

Write an import sentence with wildcard like the example, and use one inexistent class like me. God kills kittens for less than this.

Run As -> Maven Install

10/12/10 23:07:14 CET: [ERROR] The import es cannot be resolved
10/12/10 23:07:14 CET: [ERROR] UtilsA cannot be resolved to a type
10/12/10 23:07:14 CET: Build errors for war; org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.2:compile (default) on project a: Compiler errors :
error at import es.anavarro.util.*;
       ^
/home/anavarro/Documents/workspace a/war/src/main/java/a/a/a/HomeController.java:10:0::0 The import es cannot be resolved
error at UtilsA a;
^^^^
/home/anavarro/Documents/workspace a/war/src/main/java/a/a/a/HomeController.java:20:0::0 UtilsA cannot be resolved to a type

Now type this in your pom.xml (inside <dependencies> tag, create it if it doesn't exist yet).

<dependency>
    <groupId>es.anavarro</groupId>
    <artifactId>util</artifactId>
    <version>0.0.1-SNAPSHOT</version>

</dependency>

Of course, adapt it to your step-one project. Rebuild the project, if everything went ok, Maven found the dependency and resolved the "import" error.

10/12/10 23:10:30 CET: Refreshing [/war/pom.xml]
10/12/10 23:10:30 CET: [INFO] snapshot es.anavarro:util:0.0.1-SNAPSHOT: checking for updates from org.springframework.maven.snapshot
10/12/10 23:10:44 CET: Maven Builder: AUTO_BUILD 

The other error is damn logical, that class doesn't exist in util project. Let's create it, one blank "UtilsA" class, in its workspace and project, then Run as -> Maven Install. A new version will be deployed in our local repository, with the same name and version, but (invisible to the user) with a newer timestamp.

Once your "util" project is done, return to the main project, rebuild it, Maven should download your last version, find your "UtilsA" and be able to compile it all. If it doesn't compile by Eclipse build, try Maven Install, it's the important one, and forces checking and download of dependences.

That is the base of Maven approach, easy to version projects and libraries, easy to collaborate, easy to use.


See you on @anavarro_prof