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

How to exclude files from git using gitignore

During the development phase of the software in addition to the sources there are files that you want to exclude from git as binary files, eclipse settings files etc...
All these files should not be edited, so we can exclude them through a suitable configuration.

Create a local .gitignore 

A soluntion a this issue is the creation of a file with name ".gitignore" in main directory of your repositoriy.

Example

An example of gitignore file is the following:

# Compiled source #
###################
*.class
*.dll
*.exe
*.o
*.so

# Packages #
############
*.7z
*.gz
*.iso
*.jar
*.rar
*.tar
*.zip

# Logs #
########
*.log

# OS generated files #
######################
.DS_Store*
._*
.Spotlight-V100
.Trashes
ehthumbs.db
Thumbs.db

Refresh cache about gitignore

If you already have a file checked in, and you want to ignore it, Git will not ignore the file if you add a rule later. In those cases, you must untrack the file first, by running the following command in your terminal:

 git rm --cached <FILENAME>

Create a global .gitingore

Alternatively you can also create a global .gitignore file, which is a list of rules for ignoring files in every Git repository on your computer. For example create a file like local .gitignore in home with name ".gitignore_global" and run the following command into your shell:

 git config --global core.excludesfile ~/.gitignore_global

Bash commands for Navigation and File Management

Current working directory - pwd

To find out where your home directory is in relationship to the rest of the filesystem, you can use the pwd command. This command displays the directory that we are currently in.

$ pwd

List information about the files - ls

To display the directory that you are in, you use "ls" command.

$ ls

For instance, to list all of the contents in an extended form, we can use the -lflag (for "long" output):

$ ls -l

Change the working directory - cd

Begin by going back to the mydirectory directory by typing this:

$ cd mydirectory

You can use absolute or relative path.

Viewing a file - cat 

Use the "cat" command for read the contents of a file. This command concatenates one or more files to standard output. Example: 

$ cat myfile.txt

Create a file - touch

The "touch" command creates a file in your filesystem. Example:

$ touch myfile.txt

Create a directory - mkdir

The "mkdir" command creates a new directory in your filesystem. Example:

$ mkdir mydirectory

To tell mkdir that it should create any directories necessary to construct a given directory path, you can use the -p option

$ mkdir -p dir1/dir2/mydirectory

Moving and Renaming Files and Directories - mv

You can move a file to a new location using the mv command. For example, you can move myfile into the dir1 directory by typing:

$ mv myfile dir1

So to rename the dir1 directory to directory1:

$ mv dir1 directory1

Copy files and directories - cp

The cp command can make a new copy of an existing file or directory. For example, you can copy myfile.txt into same directory but with a different name (myfile2.txt):

$ cp myfile.txt myfile2.txt

Instead if you can copy a directory, use "-r" option:

$ cp -r mydir new_mydir

Remove a file - rm

The rm command remove a file. For example, you can remove myfile2.txt with the following command:

$ rm myfile2.txt

Remove a directory - rmdir

The rmdir command remove a directory. For example, you can remove new_mydir with the following command:

$ rmdir new_mydir

Alternatively you can use the following command:

$ rm -r new_mydir

Remove all files (recursively)

You can remove recursively all files with a precise name (or regular expression) from a specific path. Example: you can remove all .svn files from a your workspace, so you can execute the following command into workspace directory:

$ find . -name .svn -exec rm -rf {} \;

Find all snapshot version in a maven project

$ find . -name pom.xml | xargs grep "SNAPSHOT"

Disk Usage - du

Disk Usage - report the amount of disk space used by the specified files and for each subdirectory

$ du -h

Internal Links

May be of interest to you:

1. Create Virtual Machine with Oracle VirtualBox 
2. Bash commands about Hardaware and Network
3. How to compress and decompress files in bash