Maven

Content:

Maven abstract.

Tunning your Maven proyect

Maven standard folders

Managing dependencies with Maven

Adding a nature in Eclipse

Maven profiles inheritance

Maven is one of those useful tools that I had never heard before my current job.

"Maven's primary goal is to allow a developer to comprehend the complete state of a development effort in the shortest period of time. In order to attain this goal there are several areas of concern that Maven attempts to deal with:

• Making the build process easy
• Providing a uniform build system
• Providing quality project information
• Providing guidelines for best practices development
• Allowing transparent migration to new features"

It sounds like marketing, doesn't it? What does it mean?

- It really makes building easier: Well, I suppose it uses Ant for building, just going to the root folder, type "mvn install" and you got your compilation built. It will take any needed dependence (even Maven dependences not yet downloaded) and will compile the project using the pom.xml configuration file.

- Uniform build system: I suppose so.. The great thing is that you have all your architecture-independent configuration in one file, and it doesn't matter most of the details.

I haven't yet discovered the rest of marketing stuff in the real world, but, what makes me crazy is the dependency management.

Let's suppose I'm working in a project, and my friend J needs my project in his. He can always take my code from our repository, completed or not, it compiles or not, every release.
Certainly, he can ask me if I finished it, but is it necessary?.

Maven offers a way to synchronize throw a repository, something like uploading jars to a code repository (bad practice!). Now I can publish every version, snapshot or nigthly-build in that repository with a version number.

My contract for uploading dependences:
- Code compiles.
- Code passes unitary testing.
- Code passes other optional filters like code quality thresholds.
- New major version for backward code incompatibility.
- New minor version for new features
- Resolved bugs doesn't need additional number (if I'm wrong, I will fix this article).

Maven takes care of compiling, testing and other filters throw "mvn deploy" or "mvn install" command. This way, it makes it difficult to upload bad releases.

Every time J releases his project, Maven checks for a new release (under the same version) of my project, downloads it, compiles his project with my new version and upload his project to the repository. J doesn't even know all this :)


That's the same for Spring dependences, which came pre-configured in every Spring Maven project. You can check your pom.xml when you create a mvc project in SpringSource.

New Project -> Other -> Spring Template Project -> Spring MVC Project

Now read your pom.xml file...

My project needs spring-webmvc library with a variable version:

<dependency>
    <groupId>org.springframework</groupId>
    <artifactId>spring-webmvc</artifactId>
    <version>${org.springframework-version}</version>

</dependency>

The version I need now is:

<org.springframework.roo-version>1.0.2.RELEASE</org.springframework.roo-version>

Look for my dependencies over here, even snapshots:

<repository>
    <id>org.springframework.maven.snapshot</id>
    <name>Spring Maven Snapshot Repository</name>
    <url>http://maven.springframework.org/snapshot</url>
    <releases><enabled>false</enabled></releases>
    <snapshots><enabled>true</enabled></snapshots>
</repository>

Tune my compiler, use a variable java version:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
            <source>${java-version}</source>
            <target>${java-version}</target>

    </configuration>
</plugin>

Use this version for compiling:

<java-version>1.6</java-version>

Load this library only for testing, but don't export it afterwards:

<dependency>
    <groupId>junit</groupId>
    <artifactId>junit</artifactId>
    <version>4.7</version>
    <scope>test</scope>

</dependency>

Think of "groupid" like a sort of namespace, "artifactId" like library name, "version" is what you know you need (making possible linking old libraries without caring of new features of the same library linked by other dependencies). Finally, "scope" tells Maven if we need the library for compiling, runtime, or simply testing. Testing won't be loaded in compile time, and won't be exported when it all finish.

All the configuration in a file, architecture independent, quite clean and structured. That's Maven.

That's quite a lot for today, isn't it?