OutOfMemoryError: Increase heap size or lower gwt

Issue

You may encounter the following exception during the maven build of gwt project:

  Compiling 1 permutation
  Compiling permutation 0...
  [ERROR] OutOfMemoryError: Increase heap size or lower gwt.jjs.maxThreads
  java.lang.OutOfMemoryError: Java heap space
  at java.util.HashMap.resize(HashMap.java:462)
  at java.util.HashMap.addEntry(HashMap.java:755)
  at java.util.HashMap.put(HashMap.java:385)
  at java.util.HashSet.add(HashSet.java:200)
  at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.rescue(ControlFlowAnalyzer.java:639)
  at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer$RescueVisitor.visit(ControlFlowAnalyzer.java:438)
  at com.google.gwt.dev.jjs.ast.JParameterRef.traverse(JParameterRef.java:45)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:144)
  at com.google.gwt.dev.jjs.ast.JVisitor.acceptImmutable(JVisitor.java:152)
  at com.google.gwt.dev.jjs.ast.JMethodCall.visitChildren(JMethodCall.java:250)
  at com.google.gwt.dev.jjs.ast.JNewInstance.traverse(JNewInstance.java:84)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:125)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:120)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116)
  at com.google.gwt.dev.jjs.ast.JMethodCall.visitChildren(JMethodCall.java:248)
  at com.google.gwt.dev.jjs.ast.JMethodCall.traverse(JMethodCall.java:241)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:125)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:120)
  at com.google.gwt.dev.jjs.ast.JVisitor.accept(JVisitor.java:116)
  at com.google.gwt.dev.jjs.ast.JRunAsync.traverseOnSuccess(JRunAsync.java:101)
  at com.google.gwt.dev.jjs.impl.ControlFlowAnalyzer.traverseFromRunAsync(ControlFlowAnalyzer.java:1008)
  at com.google.gwt.dev.jjs.impl.CodeSplitter.computeAllButOneCfas(CodeSplitter.java:716)
  at com.google.gwt.dev.jjs.impl.CodeSplitter.mapExclusiveAtoms(CodeSplitter.java:976)
  at com.google.gwt.dev.jjs.impl.CodeSplitter.determineExclusivity(CodeSplitter.java:757)
  at com.google.gwt.dev.jjs.impl.CodeSplitter.execImpl(CodeSplitter.java:804)
  at com.google.gwt.dev.jjs.impl.CodeSplitter.exec(CodeSplitter.java:259)
  at com.google.gwt.dev.jjs.JavaToJavaScriptCompiler.compilePermutation(JavaToJavaScriptCompiler.java:401)
  at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:134)
  at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:195)
  at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:49)
  at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
  at java.lang.Thread.run(Thread.java:662)
          [ERROR] Out of memory; to increase the amount of memory, use the -Xmx flag at startup (java -Xmx128M ...)
       [ERROR] Unrecoverable exception, shutting down
 com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries)
  at com.google.gwt.dev.ThreadedPermutationWorkerFactory$ThreadedPermutationWorker.compile(ThreadedPermutationWorkerFactory.java:56)
  at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73)
  at java.lang.Thread.run(Thread.java:662)
       [ERROR] Not all permutation were compiled , completed (0/1)

Solution 1

To resolve this exception, you can setting, increasing memory values, the "MAVEN_OPTS" as environment variable and retry the maven build.

 MAVEN_OPTS="-Xmx2048m -XX:MaxPermSize=1024m"

Solution 2

Add "extraJvmArgs" tag under configuration tag for gwt-maven-plugin as shown in the next example:

        <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>gwt-maven-plugin</artifactId>
            <dependencies>
                <dependency>
                    <groupId>com.google.gwt</groupId>
                    <artifactId>gwt-user</artifactId>
                    <version>${gwtVersion}</version>
                </dependency>
                <dependency>
                    <groupId>com.google.gwt</groupId>
                    <artifactId>gwt-dev</artifactId>
                    <version>${gwtVersion}</version>
                </dependency>
                <dependency>
                    <groupId>com.google.gwt</groupId>
                    <artifactId>gwt-servlet</artifactId>
                    <version>${gwtVersion}</version>
                </dependency>
            </dependencies>
            <executions>
                <execution>
                    <phase>prepare-package</phase>
                    <goals>
                        <goal>compile</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
  .....
                <extraJvmArgs>-Xmx896M -Xms896m -XX:PermSize=64m -XX:MaxPermSize=128m</extraJvmArgs>
  .....
            </configuration>
        </plugin>

Technology stack

I used these solutions using:

• java 1.6
• gwt 2.5.1
• maven 3.2.1

Maven - Manage properties at build time using maven filter resource files

Sometimes you may need to use properties to contain a value that can only be supplied at build time. Maven provides a valid mechanism to handle this type of property. Indeed it is possible to put a reference to the property that will contain the value into your resource file using the syntax ${<property name>}. The property can be one of the values defined in your pom.xml, a value defined in the user's settings.xml (in $HOME/.m2), a property defined in an external properties file, or a system property.

Suppose we have this pom.xml in our project:

<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/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>

  <groupId>it.blogspot.informaticaamodomio</groupId>
  <artifactId>my-app</artifactId>
  <version>1.0-SNAPSHOT</version>
  
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project> 

Add the following configuration in your pom.xml to enable the filtering:

<build>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
      </resource>
    </resources>
</build>

To reference a property defined in your pom.xml, the property name uses the names of the XML elements that define the value, with "pom" being allowed as an alias for the project (root) element. Some properties are:

• ${project.name} refers to the name of the project;
• ${project.version} refers to the version of the project;
• ${project.build.finalName} refers to the final name of the file created when the built project is packaged;
• ${project.groupId} refers to group id of the project;
• ${parent.version} refers to the version of the parent pom.

At this point we can proceed with an example: let's add some properties to the application.properties file (in the src/main/resources directory, according pom configuration) whose values will be supplied when the resource is filtered:

application.name=${project.name}-${project.version}
application.package.name=${project.build.finalName}

you can execute the following command:

$ mvn process-resources

and the application.properties file under target/classes (and will eventually go into the jar) looks like this:

application.name=myapp-1.0
application.package.name=my-app

Now if you want add an external filter file in your pom.xml you must change the pom configuration:

<build>
    <filters>
      <filter>src/main/filters/filter.properties</filter>
    </filters>
    <resources>
      <resource>
        <directory>src/main/resources</directory>
        <filtering>true</filtering>
      </resource>
    </resources>
</build>

So create the filter.properties file and for example add a property:

devMode=true

Now you can use the value of "devMode" into application.properties:

application.name=${project.name}-${project.version}
application.package.name=${project.build.finalName}
application.devMode=${devMode}

As an alternative to the external file (filter.properties) you can create the properties into pom.xml into <properties> xml tag. 

<properties>
    <devMode>true</devMode>
</properties>

Finally you can also get values from system properties for example, java version, java home, user home. And if all this is not enough, you can define the properties via the command line using the standard Java -D parameter. 

To continue the example, let's change our application.properties file to look like this:

application.name=${project.name}-${project.version}
application.package.name=${project.build.finalName}
java.version=${java.version}
server.ip=${server.ip}

you can execute the following command:

$ mvn process-resources "-Dserver.ip=localhost"

Internal Links

May be of interest to you:

1. Getting started java project with maven
2. How to deploing jars to your artifactory server
3. Introduction to Maven Pom structure
4. Maven - Introduction to the dependency management
5. Maven - Introduction to build and reporting plugins

Maven - Introduction to build and reporting plugins

Maven is a plug-in execution framework, the plug-ins are classifiers in two types:

• Build plugins will be executed during the build and then, they should be configured in the <build/> element.
• Reporting plugins will be executed during the site generation and they should be configured in the <reporting/> element.

Build plugins

An example of build plugin is:

    <project>
      ...
      <build>
        <plugins>
          <plugin>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>maven-mybuild-plugin</artifactId>
            <version>1.0</version>
            <configuration>
                <myString>a string</myString>
                <myBoolean>true</myBoolean>
                <myInteger>10</myInteger>
            </configuration>
          </plugin>
        </plugins>
      </build>
      ...
    </project> 

The example below uses the <executions> element, this element is used when the plug-in participates in some phases of the build lifecycle:

    <project>
      ...
      <build>
        <plugins>
          <plugin>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>maven-mybuild-plugin</artifactId>
            <version>1.0</version>
            <executions>
              <execution>
                <id>execution1</id>
                <phase>test</phase>
                <configuration>
                  <myString>a string</myString>
                  <myBoolean>true</myBoolean>
                  <myInteger>10</myInteger>
                </configuration>
                <goals>
                  <goal>mygoal</goal>
                </goals>
              </execution>
            </executions>
          </plugin>
        </plugins>
      </build>
      ...
    </project>

The id "execution1" binds this configuration to the test phase.
You could configure the dependencies of the Build plugins with <dependencies> element:

    <project>
      ...
      <build>
        <plugins>
          <plugin>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>maven-mybuild-plugin</artifactId>
            <version>1.0</version>
            <executions>
              <execution>
                <id>execution1</id>
                <phase>test</phase>
                <configuration>
                  <myString>a string</myString>
                  <myBoolean>true</myBoolean>
                  <myInteger>10</myInteger>
                </configuration>
                <goals>
                  <goal>mygoal</goal>
                </goals>
              </execution>
            </executions>
            <dependencies>
              <dependency>
                <groupId>it.blogspot.informaticaamodomio</groupId>
                <artifactId>my-app</artifactId>
                <version>1.0</version>
              </dependency>
            </dependencies>
          </plugin>
        </plugins>
      </build>
      ...
    </project>

By default, plugin configuration should be propagated to child POMs, so to break the inheritance, you could uses the <inherited> element:

    <project>
      ...
      <build>
        <plugins>
          <plugin>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>maven-mybuild-plugin</artifactId>
            <version>1.0</version>
            <inherited>false</inherited>
            .......
          </plugin>
        </plugins>
      </build>
      ...
    </project>

Reporting plugins

As first statement, configuring a reporting plugin in the <reporting> or <build> elements in the pom does not have the same behavior.
For example the "mvn site" uses only the parameters defined in the <configuration> element of each reporting Plugin specified in the <reporting> element, site always ignores the parameters defined in the <configuration> element of each plugin specified in <build>. So I suggest adding it only in <reporting> element.

You can configure a reporting plugin using the <reportSets> tag. This is most commonly used to generate reports selectively when running mvn site. Example:

<project>
...
  <reporting>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-project-info-reports-plugin</artifactId>
        <version>${plugin.version}</version>
        <reportSets>
          <reportSet>
            <reports>
              <report>project-team</report>
            </reports>
          </reportSet>
        </reportSets>
      </plugin>
    </plugins>
  </reporting>
...
</project>

If you want exclude all reports, use the following reportSets configuration:

<reportSets>
    <reportSet>
        <reports/>
    </reportSet>
</reportSets>

As build plugins (for more information see [1]), you can use <inherited> element.

<inherited>false</inherited>

Internal Links

May be of interest to you:

1. Getting started java project with maven
2. How to deploing jars to your artifactory server
3. Introduction to Maven Pom structure
4. Maven - Introduction to the dependency management

Maven - Introduction to the dependency management

The "Transitive dependencies" feature allows you to avoid needing to discover and specify the libraries that your own dependencies require, and including them automatically.
The "dependency scope" is used to limit the transitivity of a dependency, and also to affect the classpath used for various build tasks. There are 6 scopes available:

• "compile" is the default scope, used if none is specified. Compile dependencies are available in all classpaths of a project.
• "provided" is much like compile, but indicates you expect the JDK or a container to provide the dependency at runtime.
• "runtime" indicates that the dependency is not required for compilation, but is for execution. It is in the runtime and test classpaths, but not the compile classpath.
• "test" indicates that the dependency is not required for normal use of the application, and is only available for the test compilation and execution phases. This scope is not transitive.
• "system" is similar to provided except that you have to provide the JAR which contains it explicitly. The artifact is always available and is not looked up in a repository.
• "import" is only supported on a dependency of type pom in the <dependencyManagement> section. It indicates the dependency to be replaced with the effective list of dependencies in the specified POM's <dependencyManagement> section. Since they are replaced, dependencies with a scope of import do not actually participate in limiting the transitivity of a dependency.

The "Dependency Management" section is a mechanism for centralizing dependency information. It can be used when two POMs extend the same parent. Example:
Pom of Project A

   <project>
      ...
      <dependencies>
        <dependency>
          <groupId>it.blogspot.informaticaamodomio</groupId>
          <artifactId>my-app</artifactId>
          <version>1.0</version>
          <exclusions>
            <exclusion>
              <groupId>it.blogspot.informaticaamodomio</groupId>
              <artifactId>my-artifact</artifactId>
            </exclusion>
          </exclusions>
        </dependency>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>3.8.1</version>
          <type>jar</type>
          <scope>test</scope>
        </dependency>
      </dependencies>
    </project>

Pom of Project B

   <project>
      ...
      <dependencies>
        <dependency>
          <groupId>it.blogspot.informaticaamodomio</groupId>
          <artifactId>my-artifact-b</artifactId>
          <version>1.0</version>
          <type>war</type>
          <scope>runtime</scope>
        </dependency>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
          <version>3.8.1</version>
          <type>jar</type>
          <scope>test</scope>
        </dependency>
      </dependencies>
    </project>

Now we can apply the dependency management adding the dependencyManagement section in Pom Parent (the order of dependencies is not relevant):

   <project>
      ...
      <dependencyManagement>
        <dependencies>
          <dependency>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>my-artifact-b</artifactId>
            <version>1.0</version>
            <type>war</type>
            <scope>runtime</scope>
          </dependency>
          <dependency>
            <groupId>it.blogspot.informaticaamodomio</groupId>
            <artifactId>my-app</artifactId>
            <version>1.0</version>
            <exclusions>
              <exclusion>
                <groupId>it.blogspot.informaticaamodomio</groupId>
                <artifactId>my-artifact</artifactId>
              </exclusion>
            </exclusions>
          </dependency>
          <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <type>jar</type>
            <scope>test</scope>
          </dependency>
        </dependencies>
      </dependencyManagement>
    </project>

Now update the dependencies section in both Poms.
Pom of Project A

   <project>
      ...
      <dependencies>
        <dependency>
          <groupId>it.blogspot.informaticaamodomio</groupId>
          <artifactId>my-artifact-b</artifactId>
          <!-- This is not a jar dependency, so we must specify type. -->
          <type>war</type>
        </dependency>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
        </dependency>
      </dependencies>
    </project>

Pom of Project B

    <project>
      ...
      <dependencies>
        <dependency>
          <groupId>it.blogspot.informaticaamodomio</groupId>
          <artifactId>my-artifact-b</artifactId>
          <!-- This is not a jar dependency, so we must specify type. -->
          <type>war</type>
        </dependency>
        <dependency>
          <groupId>junit</groupId>
          <artifactId>junit</artifactId>
        </dependency>
      </dependencies>
    </project>

Internal Links

May be of interest to you:

1. Getting started java project with maven
2. How to deploing jars to your artifactory server
3. Introduction to Maven Pom structure

Introduction to Maven Pom structure

Taking the example of a simple pom shown in [1] we analyze in detail its content:

• project tag is the top-level element in all pom.xml files.
• modelVersion tag indicates what version of the object model this pom is using.
• groupId tag indicates the unique identifier of the organization or group that created the project.
• artifactId tag indicates the unique base name of the primary artifact being generated by this project.
• packaging tag indicates the package type to be used by this artifact (e.g. JAR, WAR, EAR, etc.). If this tag is not present so the default value is jar.
• version tag indicates the version of the artifact generated by the project.
• name tag indicates the display name used for the project.
• url tag indicates where the project's site can be found.
• description tag provides a basic description of your project.

Name, url and description tags are often used in Maven's generated documentation.

Instead the dependencies tag contains the dependency list, in our example there is just junit dependency. A dependency is structured as:

 <dependency>
        <groupId>${mydependency.groupId}</groupId>
        <artifactId>${mydependency.artifactId}</artifactId>
        <version>${mydependency.version}</version>
        <scope>${mydependency.scope}</scope>
        <type>${mydependecy.type}</type> 
 </dependency>

Scope and type are optional, (if it is not present) the default value for scope is "compile". The default value for type is "jar". More details will provided in future posts.

Internal Links

May be of interest to you:

1. Getting started java project with maven
2. How to deploing jars to your artifactory server

How to deploing jars to your artifactory server

The build phase generates one or more artifacts, maven provides a local repository where to store these artifacts but It is possible to store the artifacts in a remote repository as an Artifactory server.

For deploying jars to your artifactory server you can add the following configuration in your settings.xml (in $HOME/.m2). This configuration stores the credentials for the authentication into artifactory repositories.

<servers>
    .......
    <server>
      <id>central</id>
      <username>user</username>
      <password>password</password>
    </server>
    <server>
      <id>snapshots</id>
      <username>user</username>
      <password>password</password>
    </server>
    .......
<servers>

Now yoiu can add the repository configuration always in settings.xml.

<repositories>
......
  <repository>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
    <id>central</id>
    <name>libs-releases</name>
    <url>http://myartifactory:8080/artifactory/libs-releases</url>
  </repository>
  <repository>
    <snapshots>
        <enabled>true</enabled>
        <updatePolicy>always</updatePolicy>
        <checksumPolicy>fail</checksumPolicy>
    </snapshots>
    <id>snapshots</id>
    <name>libs-snapshots</name>
    <url>http://myartifactory:8080/artifactory/libs-snapshots</url>
  </repository>
......
<repositories>

You can execute the following command:

$ mvn deploy

If your maven project version has a SNAPSHOT version then the jars will be deployed on "libs-snapshots" repo, else they will be deployed in "libs-releases".
If you want deploy the jars in a repo not configured in settings.xml file, you can use -DaltDeploymentRepository option. Example:

$ mvn deploy -DaltDeploymentRepository="otherRepoReleases::default::https://otherartifactory:8180/artifactory/otherRepoReleases"

Surely the repository requires authentication that you can configure in settings.xml as shown above.

Getting started java project with maven

To begin a development of  java project managed with maven, you need two mandatory requirement: the Java Development Kit (JDK) and Apache Maven tool both installed. An onother optional requirement but I think it indispensable the usage of an Integrated Development Environment (IDE) tool as Eclipse. 

Installing JDK

If you don't already installed the JDK than you can install the Oracle JDK available in this web page. 

Installing Apache Maven

You can refer the official guide available in this web page. If you use an ubuntu OS as the virtual machine created in previous post than you can install the latest maven version using the following commands:

To get all the available Maven package.

$ apt-cache search maven

To install the latest Maven version.

$ sudo apt-get install maven

Check post installation.

$ mvn -v

If the installation is completed with success the output will be similary as:

Apache Maven 3.3.9
Maven home: /usr/share/maven
Java version: 1.8.0_73, vendor: Oracle Corporation
Java home: /home/user/jdk1.8.0_73/jre
Default locale: en_US, platform encoding: UTF-8
OS name: "linux", version: "4.8.0-58-generic", arch: "amd64", family: "unix"

Create project by maven archetype

A maven archetype is a Maven project templating toolkit and it helps create Maven project templates for developers, and provides they with the means to generate parameterized versions of those project templates. You can use a simple maven archetype to create a new java project using a single maven command. 

Example:

$ mvn archetype:generate -DgroupId=com.blogspot.informationtechnologyarchive \
-DartifactId=first-app -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false
....
[INFO] ----------------------------------------------------------------------------
[INFO] Using following parameters for creating project from Old (1.x) Archetype: maven-archetype-quickstart:1.0
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: basedir, Value: /home/user/workspace
[INFO] Parameter: package, Value: com.blogspot.informationtechnologyarchive
[INFO] Parameter: groupId, Value: com.blogspot.informationtechnologyarchive
[INFO] Parameter: artifactId, Value: first-app
[INFO] Parameter: packageName, Value: com.blogspot.informationtechnologyarchive
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] project created from Old (1.x) Archetype in dir: /home/user/workspace/first-app
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 15.438 s
[INFO] Finished at: 2017-**********
[INFO] Final Memory: 19M/90M
[INFO] ------------------------------------------------------------------------

If you use a Linux OS you can perform the "tree command" in first-app directory the output will be:

.
├── pom.xml
└── src
    ├── main
    │   └── java
    │       └── com
    │           └── blogspot
    │               └── informationtechnologyarchive
    │                   └── App.java
    └── test
        └── java
            └── com
                └── blogspot
                    └── informationtechnologyarchive
                        └── AppTest.java

11 directories, 3 files

Now to create an executable jar you use the maven command shown below. Maven will create a target directory with the jar called first-app-1.0-SNAPSHOT.jar.

$ mvn package

[INFO] 
[INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ my-app ---
[INFO] Building jar: /home/user/workspace/first-app/target/first-app-1.0-SNAPSHOT.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.299 s
[INFO] Finished at: 2017-******
[INFO] Final Memory: 10M/167M
[INFO] ------------------------------------------------------------------------ 

Finally you can run your jar:

$ java -cp target/first-app-1.0-SNAPSHOT.jar com.blogspot.informationtechnologyarchive.App

The output in this case will be:

 Hello World!

Principal maven goals

To start execute the following command to compile your application sources:

$ mvn compile

The first time maven will need to download all the plugins and related dependencies it needs to fulfill the command. If you execute the command again, Maven will now have what it needs, so it won't need to download anything new and will be able to execute the command much more quickly.
After the successfully compiling now you want to compile and execute some unit tests:

$ mvn test

Maven downloads more dependencies this time. These are the dependencies and plugins necessary for executing the tests. Before compiling and executing the tests Maven compiles the main code. If you want only compile the unit tests:

$ mvn test-compile

Making a JAR:

$ mvn package

Maven creates only jar in target folder.

Now you'll want to install the artifact you've generated (the JAR file) in your local repository (${user.home}/.m2/repository is the default location):

$ mvn install

To remove the target directory with all the build data before starting so that it is fresh:

$ mvn clean

You can concatenate more maven goals, for example:

$ mvn clean install

If you use eclipse IDE, use the following command before importing the maven project:

$ mvn eclipse:eclipse

Similarly if you use IDEA:

$ mvn idea:idea

Eclipse IDE 

Installing Eclipse IDE

All Eclipse versions are available in this web page. I used Eclipse Neon in this post but you can use any version of eclipse for java. 

Eclipse Neon

Eclipse Maven Plugin

All commands such as those shown in the previous paragraph can be executed in eclipse through its plugin. This eclipse plugin is installed in all eclipse distributions for java. 

The use is quite intuitive: select your project, right button, select "Run As" -> "Run Configurations...." as shown in screenshot below.

Eclipse Run Configuration Item.

When the "Run Configuration" windows is loaded, you can configure your maven goal, you can see the following screenshot as example of "mvn clean install".

Maven clean install configuration.

Internal Links

May be of interest to you:

1. Create Virtual Machine with Oracle VirtualBox 

External Links

1. Oracle JDK download page
2. Installing Apache maven - official page
3. Eclipse Download - official page