How to create war package from command line

It is possible to create, modify and extract a war package from command line using the following commands.
First step, create a new war package with:

1	jar -cvf mywebapp.war myproject

Now you can modify the war already created with:

1	jar -uvf mywebapp.war myproject

Instead to extract the files from war:

1	jar -xvf mywebapp.war

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