Showing posts with label Maven. Show all posts
Showing posts with label Maven. Show all posts

Sunday, September 11, 2011

Mixing Scala and Java in a Project, Developed in Eclipse and Built by Maven

(Last updated on February 26, 2012)


 Overview

This is a tutorial showing how to setup a project (aka module) with both Scala and Java source code, to be built by Maven. In addition, this tutorial also shows how to setup the exact project in the Eclipse IDE so that developers can code and compile both Scala and Java source code in the same project.

If you only want to develop a mixed Java/Scala project in Eclipse, and you don't care about to build the project outside Eclipse using Maven and to manage Eclipse build path using Maven, you can do so using the Scala IDE for Eclipse out of box. 

Arguably, the largest advantage of the Java programming language over many other programming languages is the existence of countless libraries in Java.  Scala fully leverages this advantage of Java. Scala is very attractive for on one hand, it is a much more powerful programming language, and on the other hand, a Scala method can call almost any Java method as easy as another Java method does so. A Java method can also easily call a Scala method with certain limitations.

When develop a new project (as the term is used in the Eclipse IDE or the Maven build tool), it may be very desirable to have both Java and Scala classes in it. We may have some developers in the project who can only write Java code. We may also have to write some classes in Java in order to fit into certain frameworks or containers. Under those circumstances, a pure Scala project is not an option. If we still want to take advantage of the power of Scala, we have to mix Scala and Java in the same project. Being able to easily mix Scala and Java in the same project will greatly lower the obstacle for organizations to adopt Scala.

This tutorial is about the tricks in a Maven POM file to enable us to
  • Develop a project with both Scala and Java classes in Eclipse, where some Java methods call Scala methods, and some Scala methods call Java methods.
  • Use Maven to manage project build path in Eclipse
  • Build the project outside Eclipse using Maven
For a discussion on the advantages of using Maven to manage Eclipse project build path, see my other post.

Being able to build the project outside Eclipse using Maven makes it very easy to include that project into a larger project as a sub-project (called a module in Maven) later.

To follow this tutorial, you need:
  1. JDK 1.6 (not JDK 1.7)
  2. Eclipse Classic 3.6.x (not 3.7)
  3. The Scala IDE for Eclipse 2.0. The Scala IDE for Eclipse is an Eclipse plugin. If you need help in installing the plugin, please see the Appendix A at the end of this tutorial.
  4. Maven 2.2.1 or later
 In this tutorial, we develop a Hello World program consisting of:
  1. A Java class, GreetingInJava, with a method greet() which simply prints “Hello World!” to the console. It is normally the only class in a Java Hello World program.
  2. A Scala class GreetingInScala, with a method greet(), which instantiates a GreetingInJava instance, and call its greet() method. This is to show calling a Java method from a Scala method.
  3. A Java class, Bootstrap, with a main() method, in which a GreetingInScala instance is instantiated and the greet() method is called on that instance. This is to show calling a Scala method from a Java method.
Layout the Project

We are going to create the project outside Eclipse and to import it into Eclipse later. For more detailed about creating a project outside Eclipse and importing it into Eclipse, see my other post. Under C:\temp, create a directory structure as below.





Create Maven pom.xml

Create a pom.xml file under C:\temp\hello with the following content:



<?xml version="1.0" encoding="UTF-8"?>

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/maven-v4_0_0.xsd">
    
    <modelVersion>4.0.0</modelVersion>
    <groupId>ted-gao</groupId>
    <artifactId>scala-java-mix</artifactId>
    <version>1.0-SNAPSHOT</version>
    <name>Scala-Java mixture</name>
    <description>Showcase mixing Scala and Java</description>
    <packaging>jar</packaging>
    
    <build>
        <plugins>
            <!-- ensure that we use JDK 1.6 -->
            <plugin>
                <inherited>true</inherited>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>
            
            <plugin>
                <groupId>org.scala-tools</groupId>
                <artifactId>maven-scala-plugin</artifactId>
                <version>2.15.2</version>
                <executions>
                    <!-- Run scala compiler in the process-resources phase, so that dependencies on
                         scala classes can be resolved later in the (Java) compile phase -->
                    <execution>
                        <id>scala-compile-first</id>
                        <phase>process-resources</phase>                        
                        <goals>
                            <goal>compile</goal>
                        </goals>
                        </execution>

                        <!-- Run scala compiler in the process-test-resources phase, so that dependencies on
                             scala classes can be resolved later in the (Java) test-compile phase -->                    
                        <execution>
                        <id>scala-test-compile</id>
                        <phase>process-test-resources</phase>
                        <goals>
                            <goal>testCompile</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>build-helper-maven-plugin</artifactId>
                <executions>
                    <!-- Add src/main/scala to source path of Eclipse -->
                    <execution>
                        <id>add-source</id>
                        <phase>generate-sources</phase>
                        <goals>
                            <goal>add-source</goal>
                        </goals>
                        <configuration>
                            <sources>
                                <source>src/main/scala</source>
                            </sources>
                        </configuration>
                    </execution>
                      
                    <!-- Add src/test/scala to test source path of Eclipse -->
                    <execution>
                        <id>add-test-source</id>
                        <phase>generate-test-sources</phase>
                        <goals>
                            <goal>add-test-source</goal>
                        </goals>
                        <configuration>
                            <sources>
                                <source>src/test/scala</source>
                            </sources>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            
            <!-- to generate Eclipse artifacts for projects mixing Scala and Java -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-eclipse-plugin</artifactId>
                <version>2.8</version>
                <configuration>
                    <downloadSources>true</downloadSources>
                    <downloadJavadocs>true</downloadJavadocs>
                    <projectnatures>
                        <projectnature>org.scala-ide.sdt.core.scalanature</projectnature>
                        <projectnature>org.eclipse.jdt.core.javanature</projectnature>
                    </projectnatures>
                    <buildcommands>
                        <buildcommand>org.scala-ide.sdt.core.scalabuilder</buildcommand>
                    </buildcommands>
                    <classpathContainers>
                        <classpathContainer>org.scala-ide.sdt.launching.SCALA_CONTAINER</classpathContainer>
                        <classpathContainer>org.eclipse.jdt.launching.JRE_CONTAINER</classpathContainer>
                    </classpathContainers>
                    <excludes>
                        <!-- in Eclipse, use scala-library, scala-compiler from the SCALA_CONTAINER rather than POM <dependency> -->
                        <exclude>org.scala-lang:scala-library</exclude>
                        <exclude>org.scala-lang:scala-compiler</exclude>
                    </excludes>
                    <sourceIncludes>
                        <sourceInclude>**/*.scala</sourceInclude>
                        <sourceInclude>**/*.java</sourceInclude>
                    </sourceIncludes>
                </configuration>
            </plugin>
            
            <!-- When run tests in the test phase, include .java and .scala source files -->
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.8.1</version>
                <configuration>
                    <includes>
                        <include>**/*.java</include>
                        <include>**/*.scala</include>
                    </includes>
                </configuration>
            </plugin>
        </plugins>
    </build>

    <dependencies>
        <dependency>
            <groupId>org.scala-lang</groupId>
            <artifactId>scala-library</artifactId>
            <version>2.9.0</version>
        </dependency>
    </dependencies>
</project>

It is OK for Java classes/interfaces to depend on Scala classes/objects because Scala classes/objects are compiled before Java classes/interfaces. It is also OK for Scala classes/objects/traits to depend Java classes/interfaces because Scala classes/objects/traits can be compiled against both Java source code and bytecode.


Create Eclipse Artifacts

Run Maven Eclipse plugin to create Eclipse project artifacts and configure the Eclipse workspace with path variable M2-REPO pointing to the local Maven repository. If you need help to do those tasks, please see my other post.

Create Java and Scala Classes

In Eclipse, create the following two Java classes and one Scala class.

GreetingInJava is a simple Java class.

package mix.java.scala;

package mix.java.scala;

public class GreetingInJava {
    public void greet() {
        System.out.println("Hello World!");
    }
}

GreetingInScala is a simple Scala class that calls Java.

package mix.java.scala

class GreetingInScala {
    def greet() {
        val delegate = new GreetingInJava
        delegate.greet()
    }
}

Bootstrap is a simple Java class that calls Scala. If you need help to create new Scala classes in Eclipse, see the Appendix B at the end of this tutorial.

package mix.java.scala;

public class Bootstrap {

    public static void main(String[] args) {
        GreetingInScala scala = new GreetingInScala();
        scala.greet();
    }
}

Run Bootstrap.java in Eclipse

Right click Bootstrap.java in the source editor in Eclipse. From the context menu, select Run As... -> Java Application.

You will see string "Hello World!" is printed to the console.

Build the Project Outside Eclipse, Using Maven

Open a command line window and cd to C:\temp\hello, execute the following command:

mvn install

You will see Maven compile the three Java and Scala classes and package them into a jar file.

Run Bootstrap.java outside Eclipse


Open a command line window and cd to C:\temp\hello, if you have not done so. Execute the following command:


mvn exec:java -Dexec.mainClass=mix.java.scala.Bootstrap

You will see "Hello World!" is printed to the command line window.


Conclusion


With the pow.xml in this tutorial, we will be able to create projects with Java and Scala source code mixed. We will be able to develop both Java and Scala source code in Eclipse. We will also be able to run the Java and Scala classes in Eclipse. We will also be able to build the project and to execute the classes outside Eclipse using Maven.

Appendix A – Installing the Scala IDE for Eclipse

On the Eclipse workbench, select Help -> Install New Software ...



When the Install dialog box appears, click the Add button. When the Add Repository dialog box appears, fill in a name for the plugin and the URL of the update site for the Scala IDE for Eclipse, and click the OK button.


Back to the Install dialog box, check all available plugins as shown on the snapshot below.


When you see the following warning, ignore it and click the OK button.


When the installation is finished, you need to restart Eclipse.

Appendix B – Creating New Scala Class in the Scala IDE for Eclipse

On the Package Explorer view, right click the desired package. From the context menu, select New -> Other… When the New dialog box appears, select Scala Wizards -> Scala Class.

[If you are also interested in developing Scala programs using Eclipse and sbt (instead of Maven) together, please read Using Eclipse and sbt in Scala Programming.]

Monday, September 5, 2011

Using Maven to Manage Library Dependencies in Eclipse without m2eclipse

Eclipse has a built-in function managing library dependencies. By the usual practice, for each project (as the term means in Eclipse), one downloads the libraries (i.e. jar files) and places them under a directory name lib under the project base directory, and adds the jar files onto the project’s Build Path. This practice has the following disadvantages:
  • One has to figure out what jar files to download and where to place them. 
  • When a library itself depends on other libraries, one has to figure out what the dependencies are, to download them and to add them onto the project’s Build Path. And repeats recursively. 
  •  It is difficult to reuse part of a project’s Build Path for a new project since there is not dependency tree information about the Build Path accessible for Eclipse users 
  •  There is not standard way to share the Build Path in a team 
  •  It is difficult to manage version of the libraries.
A better option is to manage library dependencies of Eclipse projects using Maven. It brings the following advantages:
  • Maven will take care of the jar file downloading. And the downloaded jars will be placed in the local Maven repository with standard layout. 
  •  Maven will take care of transitive dependencies. 
  •  The (direct) dependencies are captured in Maven POM files, which can be easily kept in source control system and can be easily shared within a team. Besides, library versions can be explicitly specified in POM files.
This tutorial shows how to manage library dependencies in an example Eclipse project using Maven without m2eclipse. m2eclipse (now officially called Maven Integration for Eclipse) is a plugin in Eclipse to integrate with Maven. This tutorial, however, does not discuss m2eclipse.  It is assumed that the readers have already installed Maven (and Eclipse). The project is a Hello World program. It, however, uses logback, a third party logging library, to trace program execution into a log file. With a little knowledge about logback, we know that the project depends on the logback-classic library. So in our pom.xml, we are going to have the following dependency

        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>0.9.29</version>
        </dependency>

(If you need help to find the exact groupId/artifactId/version, please read my post on that topic.)

In fact, logback-classic itself depends on logback-core and slf4j-api, but we do not have to do anything since Maven will take care of it. It is a huge benefit of letting Maven to manage library dependencies inside and outside Eclipse.

When Eclipse is launched, the user must select a workspace by selecting its base directory. If the directory does not exist, Eclipse will create a new workspace with that directory as the base directory. When a user creates a new java project, the user must select a directory as the base directory of the project. A project base directory can be either inside or outside the workspace base directory. The outside option is better. With this option, we decouple projects from workspace. Eclipse workspaces are not version compatible. That means that when a user upgrades his/her Eclipse from version 3.6 to 3.7, he/she has to create a new workspace, to pull the project source code out of the old workspace, and to place them into the new workspace. That work is cut down to the minimum when projects are decoupled from workspace.  In this tutorial, we place the project base directory outside the workspace base directory.

Creating and Configuring a Workspace
Under C:\temp, create a new directory called eclipseworkspace. Open a command line console, cd into C:\temp\eclipseworkspace, and execute the following command:

mvn -Declipse.workspace=. eclipse:configure-workspace

It creates a new workspace and a path variable called M2_REPO pointing to the local maven repository. The path variable will be used later on project Build Paths.

Creating a Project
Under C:\temp, create a new directory hello. Inside hello, create directories as below. 

Create a pom.xml under hello with content as following.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/maven-v4_0_0.xsd">
   
    <modelVersion>4.0.0</modelVersion>
    <groupId>ted-gao</groupId>
    <artifactId>dependency-tutorial</artifactId>
    <version>1.0-SNAPSHOT</version>
    <name>Dependency-Management-Tutorial</name>
    <description>Tutorial on managing dependencies in Eclipse using Maven</description>
    <packaging>jar</packaging>
   
    <build>
        <plugins>
            <!-- ensure that we use JDK 1.6 -->
            <plugin>
                <inherited>true</inherited>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>           
        </plugins>
    </build>

    <dependencies>
        <dependency>
            <groupId>ch.qos.logback</groupId>
            <artifactId>logback-classic</artifactId>
            <version>0.9.29</version>
        </dependency>
    </dependencies>

</project>

In a command line console, cd into hello, and execute the following command:

mvn eclipse:eclipse

It creates Eclipse artifacts for a project.

Please notice the following output from Maven during above command execution:

Downloading: http://repo1.maven.org/maven2/ch/qos/logback/logback-classic/0.9.29/logback-classic-0.9.29.pom
Downloaded: http://repo1.maven.org/maven2/ch/qos/logback/logback-classic/0.9.29/logback-classic-0.9.29.pom (13 KB at 38.9 KB/sec)
Downloading: http://repo1.maven.org/maven2/ch/qos/logback/logback-parent/0.9.29/logback-parent-0.9.29.pom
Downloaded: http://repo1.maven.org/maven2/ch/qos/logback/logback-parent/0.9.29/logback-parent-0.9.29.pom (14 KB at 27.0 KB/sec)
Downloading: http://repo1.maven.org/maven2/ch/qos/logback/logback-core/0.9.29/logback-core-0.9.29.pom
Downloaded: http://repo1.maven.org/maven2/ch/qos/logback/logback-core/0.9.29/logback-core-0.9.29.pom (7 KB at 14.5 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.6.1/slf4j-api-1.6.1.pom
Downloaded: http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.6.1/slf4j-api-1.6.1.pom (3 KB at 6.2 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/slf4j/slf4j-parent/1.6.1/slf4j-parent-1.6.1.pom
Downloaded: http://repo1.maven.org/maven2/org/slf4j/slf4j-parent/1.6.1/slf4j-parent-1.6.1.pom (10 KB at 19.1 KB/sec)
Downloading: http://repo1.maven.org/maven2/ch/qos/logback/logback-classic/0.9.29/logback-classic-0.9.29.jar
Downloaded: http://repo1.maven.org/maven2/ch/qos/logback/logback-classic/0.9.29/logback-classic-0.9.29.jar (239 KB at 486.7 KB/sec)
Downloading: http://repo1.maven.org/maven2/ch/qos/logback/logback-core/0.9.29/logback-core-0.9.29.jar
Downloaded: http://repo1.maven.org/maven2/ch/qos/logback/logback-core/0.9.29/logback-core-0.9.29.jar (308 KB at 630.9 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.6.1/slf4j-api-1.6.1.jar
Downloaded: http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.6.1/slf4j-api-1.6.1.jar (25 KB at 51.1 KB/sec)

It shows that even though we only specified that our project depends on logback-classic, Maven figured out that logback-classic depends on logback-core and slf4j-api and included them in our project. Besides, Maven downloaded all the three libraries from the Maven Central Repository.

Developing with Eclipse

Launch Eclipse. When asked to select a workspace, select C:\temp\eclipseworkspace.



From Eclipse Workbench, select the menu item File -> Import…



On the Import dialog box, select General -> Existing Projects into Workspace and click the Next button.



Still on the Import dialog box, browse to select C:\temp\hello as the project root directory, and click the Finish button.



Now the Eclipse Workbench should look like the snapshot below.



Let’s see how well Maven managed library dependencies for us. Right click the project dependency-tutorial in the Package Explorer view, from the context menu, select Properties. On the Properties for dependency-tutorial dialog box, select Java Build Path on the left pane, and the Libraries tab on the right pane. We can see that three libraries, viz. logback-classic, logback-core, and slf4j-api, have been added to the Java Build Path – Maven has done that for us. The three library jar files are in the local Maven repository. The path variable M2_REPO points to the base directory of the local Maven repository.



Now, in Eclipse, create a file called logback.xml under resources. It is a logback configuration file. Write the following content into logback.xml.

<configuration>
  <appender name="FILE" class="ch.qos.logback.core.FileAppender">
    <file>dependency-tutorial.log</file>

    <encoder>
      <pattern>%date %level [%thread] %logger{10} [%file:%line] %msg%n</pattern>
    </encoder>
  </appender>

  <root level="trace">
    <appender-ref ref="FILE" />
  </root>
</configuration>

Create a Java class with full name tutorial.dependency.HelloWorld.

package tutorial.dependency;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloWorld {
    public static void main(String[] args) {
        Logger logger = LoggerFactory.getLogger("tutorial.dependecy.HelloWorld");

        logger.trace("Before saying hello.");
        System.out.println("Hello World!");
        logger.trace("After saying hello.");
    }
}
Run HelloWorld. We will see that Hello World is printed on the console. Refresh the dependency-tutorial project, we will see a new file named dependency-tutorial.log. Open it. It has the following content:

2011-09-06 21:54:26,163 TRACE [main] t.d.HelloWorld [HelloWorld.java:10] Before saying hello.
2011-09-06 21:54:26,166 TRACE [main] t.d.HelloWorld [HelloWorld.java:12] After saying hello.

That is the work done by logback.

Update Dependencies


If you need to change library dependencies later. Change the dependency specification in the pom.xml file (i.e. <dependencies>). Execute mvn eclipse:eclipse again. And right click the project in Eclipse, and select Refresh from the context menu.

[If you are also interested in using sbt to manage library dependencies in Eclipse for Scala programs, please read Using Eclipse and sbt in Scala Programming.]


Tuesday, August 9, 2011

Inheritance and Overriding in Maven

Maven provides a mechanism for a project to inherit project information from its parent project. Information that a project can inherit from its parent project include:
  • Dependencies under <dependencies>
  • Dependencies under <dependencyManagement>
  • Properties under <properties>
  • Plugin list and configurations
  • And so on …
 Of course, all inherited information can be overridden. For example, declaring a property named version in a project itself will override the same property inherited from its parent project.

Any Maven configuration may have property references, in the form of ${property-name}, in it. An interesting question is: when a property is overridden, are all other inherited configurations with ${the-property-name} in them effectively different between the child and the parent, depending on the value of that property for each of them?

The issue can be illustrated with an example. In this example, there are two sibling projects A and B, both have project P as their parent. In project P’s POM file, there is a property named development.team, and a configuration of the Maven jar plug-in as described in the following POM fragment:
...
<properties>
    ...
    <development.team>tiger</development.team>
    ...
</properties>
...
<plugins>
    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-jar-plugin</artifactId>

        <configuration>
            <archive>
                ...
                <manifestEntries>
                    <development-team>${development.team}</ development-team >
                </manifestEntries>
            </archive>
        </configuration>
    </plugin>
<plugins>

The configuration of Maven jar plugin will let Maven to write an entry named development-team into the manifest file for the jar file built out of the project associated with the POM. The entry may look like:

Development-team: tiger

In our example, both project A and B are jar packaging project. Both project A and B inherited the property and plugin configuration from project P. Project A, however, overrides the property with the following POM fragment in its own POM:
<properties>
    <development.team>wolf</development.team>
</properties>

Here comes our question. What will shows up as development-team in the manifest files in the jar files built out of project A and B.  A reasonable expectation, in the spirit of Open-Close principle, is that it is wolf for A, and tiger for B. Is it the way of Maven? I searched Maven documents but could not find a specification in this aspect. So I did an experiment and found that Maven does work this way. 

Tuesday, July 19, 2011

Finding the Artifact ID of a Java Library

To build one’s Java applications with Maven, one has to at first find the group ID, the artifact ID, and the version number that together identify each of the Java libraries (artifacts, in Maven’s term) used by each of the Java applications. One also has to find where (i.e. a Maven repository) the artifacts reside. Fortunately the Maven Central Repository contains almost all popular open source Java libraries. And it is very easy to find the artifact ID, the group ID, and the version number of a Java library in that repository through The Search Engine for Maven Central.

For example, I was developing a Java application that used the StringTemplate Java template engine created by Terence Parr. The StringTemplate website told me that the latest version of StringTemplate then was 4.0.3. The website also said that I would need to download two jar files, ST-4.X.jar and antlr-complete.jar, to my classpath. That is, however, not the way with Maven. So I visited The Search Engine for Maven Central, and searched “StringTemplate”. The search engine found about seven artifacts (i.e. Java libraries) in the repository. One has the group ID “org.antlr”,  the artifact ID “stringtemplate, and the  latest version number 4.02. It is what I need. So I added the following fragment into my POM file:

<dependency>
    <groupId>org.antlr</groupId>
    <artifactId>stringtemplate</artifactId>
    <version>4.0.2</version>
</dependency>

It works! Since my application does not directly use Antlr. I do not have to do anything about it. Obviously StringTemplate uses Antlr but Maven will handle it automatically. With the Advanced Search feature of the The Search Engine for Maven Central, one can even search by Java class names.

There is an alternative Maven repository search engine at http://mvnrepository.com/. It works pretty well too. When I cannot find what I need using The Search Engine for Maven Central, I will try MVNRepository. Often it helps.

Background

Most Java applications use Java libraries. Usually one has to download each Java library to the same computer where the JVM runs, and to place the library file (usually a .jar file) on the classpath of the JVM. If one Java library uses other Java libraries, one has to find out what they are and from where one can get them, and download them to the classpath of the JVM; and repeat it recursively. That is quit a headache. In addition, when one deploys that Java application to another computer, one has to repeat all the works to make the libraries available on that computer. To do so, one has to keep well the knowledge of the dependency tree somewhere in an ad hoc manner.

Maven helps by explicitly keeping direct dependencies on other libraries in the Project Object Model (POM file) and handling indirect dependency automatically. In Maven’s term, a Java library is an artifact, and an artifact is usually identified by a group ID, an artifact ID, and a version number. For more information about Maven, check out the Apache Maven website, and the (free) Sonatype Maven Books.