One of the key benefits of PowerShell is its object-oriented nature. Instead of working with text-based output like traditional command-line interfaces, PowerShell returns objects that can be easily manipulated using its built-in cmdlets (pronounced “command-lets”). This makes it easy to automate complex tasks, as administrators can pipe the output of one cmdlet to another, building up a chain of commands that perform a series of operations on an object.

Commands To Find Other Commands

I consider this set of commands very useful because they are used to discover other commands. These commands help in discovering syntax, usage, and members of other commands so you don’t have to memorize the full commands catalog. Here are the most useful and frequently used commands that you must know:

Essential PowerShell Commands

Here is a list of basic PowerShell commands that you should know.

The post Basic PowerShell Commands That You Should Know appeared first on Automation Dojos.

Oh-My-Posh is a powerful custom prompt engine for any shell that has the ability to adjust the prompt string with a function or variable. It does not only beautify the terminal, but it also increases the work efficiency by adding lot of features related to usability, hints, history etc. It also comes with a good number of pre-built themes for your prompt, so you can either choose one, customize a pre-built theme or even create a new one.

The post How To Install Oh-My-Posh On Windows PowerShell appeared first on Automation Dojos.

Maven offers a good set of commands and CLI Options to carry out wide range of Dev tasks. Most of these commands are in fact Maven build life cycles, phases and goals.

Here is a list of common Maven commands along with explanation. But before we go through the Maven commands, it is good idea to understand the structure or syntax of Maven commands along with a brief about the Maven lifecycle, phases and goals.

The post Maven Common Commands Reference appeared first on Automation Dojos.

Maven’s Sequential Execution

In Maven, you have the option of executing a build phase or build goal. But unlike build goals, which can be called and executed individually, Maven follows a sequential or hierarchical order of execution for build phases.

For example, if you run a phase that is at level 5 in the life cycle hierarchy, all preceding phases (i.e., phase 1 to 4) are also executed. This will become clearer with explanations in the subsequent sections.

Let us understand, what do we mean by ‘sequential execution‘ in a more realistic way, by looking at what happens when you execute build phases or build goals:

Maven Build Life Cycles

The Maven build life cycle is divided into ‘Build Phases’. These build phases are further divided into ‘Build Goals‘. [Lifecycle > Phases > Goals]

By default, Maven contains the following three built-in build life cycles:

Each of these build lifecycles is defined by a different list of build phases, wherein a build phase represents a stage in the lifecycle as shown in the below table:

For a complete listing of Maven’s life cycle and phases refer to the above table.

Executing Maven Life Cycles

It is not possible to execute the ‘default’ build life cycle directly (not permitted). In fact, there is no command for executing any Maven life cycle ‘directly’. Instead, you execute a life cycle by calling single or multiple ‘build phases’ contained inside the lifecycle in such a way that all preceding build phases of the lifecycle automatically get executed (due to the sequential execution nature of Maven) giving you the net result equivalent to full life cycle execution.

For a more concrete example, consider the Maven’s default life cycle phases as mentioned below in the section ‘Build Phases for Default Life Cycle’, and suppose you want to execute the entire default life cycle. if you executed ‘deploy’ phase of the default Maven lifecycle by calling –

mvn deploy

The above command would execute each default lifecycle phase in the order (validate > compile > test > package > integration-test > verify > install), before executing ‘deploy’ phase itself.

_{Note: The above list only shows some of the main phases. There are however more phases involved but not shown here. For a complete list refer to ‘Default Life Cycle‘ in the above section.}

Hence you only need to call the last build phase to be executed, (which is the ‘deploy’ phase in this case), and doing so, automatically executes preceding phases.

As mentioned, though it is not possible to execute the ‘default’ life cycle directly, you can however execute a specific build phase within the default build life cycle to achieve your objective as shown in the above example wherein we executed the ‘deploy’ build phase of the default Maven’s default life cycle.

All the phases contained in the default life cycle, clean life cycle, and site life cycle have been explained in the below section.

Maven Build Phases

A Maven build phase represents a stage in the Maven build lifecycle. Each phase is responsible for a specific task. Usually, a Maven life cycle would contain multiple phases.

You can execute a build phase located inside a build life cycle by passing the name of the build phase to the Maven command. Maven would evaluate what build life cycle the specified build phase belongs to, hence you don’t need to explicitly specify which build life cycle.

Here are some build phase commands:

mvn compile
mvn package

Build Phases for Default Life Cycle

The default Maven lifecycle consists of the following main 8 phases (out of total 23 phases) for the building project. These lifecycle phases are executed sequentially as explained in the earlier section

Here are some build phase commands for Maven’s Default Life Cycle:

mvn verify
mvn compile

Build Phases for Clean Life Cycle

Maven’s ‘clean’ life cycle contains the following phases as shown in the below table:

Here are examples for executing Maven’s Clean Life Cycle phases:

mvn clean
mvn post-clean (not recommended)

Build Phases for Site Life Cycle

Maven’s ‘site’ life cycle contains the following phases as shown in the below table:

Here are examples for executing Maven’s Site Life Cycle phases:

mvn site
mvn pre-site (not recommended)

Avoid Calling Intermediary Phases

Please note that there are some special ‘sort of’ phases that are not recommended to be called directly from the Maven command line.

The phases named with hyphenated words (pre-, post-, or process-*) are not usually directly called from the command line. Such ‘phases’, sequence the build, producing intermediate results that are not useful outside the build.

Maven Build Goal

As mentioned earlier, a ‘Build Phase’ is made up of one or more ‘Plugin Goals’, where a ‘plugin goal’ represents a specific task that contributes to the building and managing of a project. It may be bound to zero or more build phases. If a goal is bound to one or more build phases, that goal will be called in all those phases.

Maven goals can also be run independently or else they get executed as part of the build phase if attached to a build phase.

Also, note that unlike ‘build phases’ the ‘build goal’ doesn’t have the concept of ‘sequential execution’ since they are individual and independent ‘unit of work’ or ‘task’.

Executing Maven Build Goals

The syntax for running a specific goal, without executing its entire phase and the preceding phases is:

mvn <Plugin_Name>:<Goal_Name>

Here are two examples for executing Maven Goals independently of the build phase or life cycle:

compiler:compile – Executes the compile goal from compiler plugin
compiler:testCompile - Executes testcompile goal from compiler plugin.
surefire:test - Executes test goal from the surefire plugin

Adding Goals to Phases

While customizing your Maven project, you may often require assigning new tasks to build phases, in other words adding new goals to build phases or even adding independent goals. You can generally achieve this easily via packaging and plugins. These are explained briefly in the subsequent sections.

Maven Project Packaging

This is perhaps the most common and easy way for defining ‘Goals’ (tasks). You can set the packaging for your project via the POM element called <packaging>.  Based on the defined ‘packaging’ a specific set of goals bind to a particular phase.

For example, the jar packaging will bind the following goals to build phases of the default lifecycle.

Some of the valid packaging values are jar, war, ear and pom. If no packaging value has been specified, it will default to jar. You can refer to more details about packaging and their default bindings here – https://maven.apache.org/ref/3.8.5/maven-core/default-bindings.html

Maven Plugins

Maven Plugins are artifacts that provide ‘Goals’ to Maven, in other words, Maven plugins define one or more goals that represent the functionality or capability of that plugin. For example, the Compiler plugin has two goals: compile and testCompile.

Also, a plugin may define a set of goals that may not necessarily all bound to the same phase but rather could be distributed or used across phases.

Depending on your requirement, you can either choose to use an existing plugin from the Maven repository or you can write your own custom plugin as well. Here is an example of typical <plugin> configuration in pom.xml

    <plugins>
        <plugin>
            <groupId>com.adojos</groupId>
            <artifactId>my-custom-maven-plugin</artifactId>
            <version>0.0.1-SNAPSHOT</version>
            <executions>
                <execution>
                    <goals>
                        <goal>my-custom-goal</goal>
                    </goals>
                </execution>
            </executions>
            <configuration>
                <scope>test</scope>
            </configuration>
        </plugin>
    </plugins>

The post Maven Build Life Cycles, Phases and Goals appeared first on Automation Dojos.

Maven offers a good set of commands and CLI Options to carry out wide range of Dev tasks. Most of these commands are in fact Maven build life cycles, phases and goals.

Here is a list of common Maven commands along with explanation. But before we go through the Maven commands, it is good idea to understand the structure or syntax of Maven commands along with a brief about the Maven lifecycle, phases and goals.

The post Maven CLI Options and Switches Reference appeared first on Automation Dojos.

Maven Basics

Maven automates the steps involved in building a software application like adding the JAR files, compiling code, running unit tests, creating the output jar/war file, etc. This makes the code less error-prone. Maven uses an XML configuration file known as the POM file. Developers need to specify information like the JAR files required by an application, the type of output artifact (jar,war, etc). Maven then uses the instructions in the POM file to build the application.

Eclipse Maven Integration

Most of the recent Eclipse releases already include Maven. So, developers do not need to do anything special to install Maven in Eclipse.  However, some earlier versions of Eclipse do not include Maven, so it needs to be installed explicitly from the Eclipse marketplace. Once Maven is set up with Eclipse, it allows you to easily create a Maven project and use all the Maven features like dependency resolution within Eclipse itself.

Create Maven Project with Archetype in Eclipse

Maven archetype provides a template that can be used to create a particular type of Maven project. If a Maven project is created with an archetype selection, Maven creates the POM file accordingly. Some of the common Maven archetypes are as follows:

In order to create a Maven project with a webapp archetype, the following steps need to be followed:

Create new artefact of type ‘Other’

On Eclipse main menu, navigate to ‘File > New’ and select ‘Other’

Select Maven Project

Select the option ‘Maven Project’ and click Next.

Uncheck ‘Create Simple Project‘

Leave the Create a Simple Project (skip archetype selection) checkbox unchecked. Click Next

Use filter ‘maven-archetype-webapp‘

Select maven-archetype-webapp.

Input Group Id and Artifact Id

Enter a value for Group Id and Artifact Id. Change version and package if required. Click Finish

Verify New Maven project in Eclipse

This creates a Maven project in Eclipse with the Maven directory structure and POM file as follows

Finish!

Finish! This POM file can then be modified by adding dependencies and other information as required.

The post How To Create Maven Project in Eclipse With Archetype appeared first on Automation Dojos.

Maven is a very popular build and dependency management tool. Eclipse is an IDE that helps developers write and run Java code easily. In this article, I will be explaining how you can create a Maven project in Eclipse.

Maven Basics

Maven automates the steps involved in building a software application like adding the JAR files, compiling code, running unit tests, creating the output jar/war file, etc. This makes the code less error-prone. Maven uses an XML configuration file known as the POM file. Developers need to specify information like the JAR files required by an application, the type of output artifact (jar,war, etc). Maven then uses the instructions in the POM file to build the application.

Eclipse Maven Integration

Most of the recent Eclipse releases already include Maven. So, developers do not need to do anything special to install Maven in Eclipse.  However, some earlier versions of Eclipse do not include Maven, so it needs to be installed explicitly from the Eclipse marketplace. Once Maven is set up with Eclipse, it allows you to easily create a Maven project and use all the Maven features like dependency resolution within Eclipse itself.

Creating a Simple Maven Project

In order to create a simple Maven project in Eclipse, the following steps need to be followed:

Create new artefact of type ‘Other’

From menu File > New select ‘Other’

Select Maven Project. Click Next

On the ‘new project’ wizard select ‘Maven Project’

Select ‘Create a Simple Project’

Click the Create a Simple Project (skip archetype selection) checkbox. Click Next

Enter value for Group Id & Artifact Id.

Change version and packaging

Change version and packaging if required (This is an optional step). Click Finish

New Maven Project Created

This creates a Maven project in Eclipse with the Maven directory structure and POM file as follows

View Your POM File

The default POM created has the group id, artifact id, version and packaging specified at the time of creation as follows

Finish!

This POM file can then be modified by adding dependencies and other information as required.

The post How To Create Maven Project in Eclipse Without Archetype appeared first on Automation Dojos.

Table of Contents

• 1. What is Maven Compiler Plugin
• 2. Default Configuration
• 3. Common Compilation Error
• 4. Custom Configuration Java 8 or Earlier
  • 4.1. Configure using POM Properties
  • 4.2. Configure using -source & -target
  • 4.3. Configure using ‘compilerVersion’
    • 4.3.1. Improvise – Use variable for Path
    • 4.3.2. Improvise – Pass args to compiler
      • Method 1: Using <configuration> element
      • Method 2: Using explicit <compilerArgs>
• 5. Custom Configuration Java 9 and Beyond
  • 5.1. Configure using POM Properties
  • 5.2. Configure using plugin <configuration>

1. What is Maven Compiler Plugin

The ‘Maven Compiler Plugin’ or more commonly known as ‘Maven Java Compiler’ is used to compile the source code of your project/application.

Internally this plugin uses the standard ‘javac’ compiler (JDK) and as of version 3.0 of this plugin the default compiler is javax.tools.JavaCompiler

Unlike other Maven plugins, the ‘maven compiler plugin’ is ‘in-built’ and ‘implicit’ in nature. This plugin has two goals, which are already bound to specific phases of the default lifecycle:

As mentioned earlier, the maven compiler plugin is called implicitly and automatically by the maven lifecycle in the appropriate phase. Hence you don´t necessarily need to define it inside ‘pom.xml’ it shall be downloaded and executed automatically by maven as and when required. However, we can certainly define and configure custom behavior and attributes for this plugin by specifying it in the ‘pom.xml’.

2. Default Configuration

As per the default behavior, the ‘maven compiler plugin’ compiles source code compatible with Java 5 (also written as Java 1.5), irrespective of the JDK installed on your machine. However, with custom configuration in your ‘pom.xml’ you can override this behavior and specify your own version of compiler and compatibility version.

3. Common Compilation Error

While starting with Maven projects, it is very common to encounter the below error associated with this plugin. This is nothing but the default behavior as mentioned in the above paragraph and can be rectified by using one of the below mentioned custom configurations for your maven java compiler.

[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR :
[INFO] -------------------------------------------------------------
[ERROR] Source option 5 is no longer supported. Use 6 or later.
[ERROR] Target option 1.5 is no longer supported. Use 1.6 or later.
[INFO] 2 errors
[INFO] -------------------------------------------------------------

4. Custom Configuration Java 8 or Earlier

If you are using Java 8 or earlier, you can set the Maven Java Compiler version in your POM file using one of the following three methods:

Let us start with a standard bare-bone ‘pom.xml’ file and insert our custom configuration for ‘Maven Compiler Plugin’ eventually by three different methods.

<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>com.testoxide</groupId>
  <artifactId>maven-quick-start</artifactId>
  <version>1.0</version>
</project>

4.1. Configure using POM Properties

In this method rather than tweaking the ‘maven compiler’ configuration or ‘build’ configuration’ directly, you can use the POM properties to set the compiler (JDK) versions.

This is the most simple but probably least reliable way. However, which option works best for you depends on the setup of your project and specific requirements i.e. depend on a case by case basis.

<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>com.testoxide</groupId>
  <artifactId>maven-quick-start</artifactId>
  <version>1.0</version>
    <properties>
    <maven.compiler.source>1.8</maven.compiler.source>
    <maven.compiler.target>1.8</maven.compiler.target>
  </properties>
</project>

Using the above configuration should give you output classes both compiled and compatible with the specified java (compiler) version which is Java 8 in this case.

4.2. Configure using -source & -target

Another, preferred way for forcing a specific compiler version is by modifying the default parameter values of ‘-source’ and ‘target’ directly in the plugin settings as below.

Here we are setting the JDK/JRE version for both source and target to 1.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>com.testoxide</groupId>
  <artifactId>maven-quick-start</artifactId>
  <version>1.0</version>

  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <source>1.8</source>
          <target>1.8</target>
        </configuration>
      </plugin>
    </plugins>
  </build>

</project>

4.3. Configure using ‘compilerVersion’

You can use this method to compile your code with a ‘very specific’ JDK version, even if it is different than the one used to launch Maven itself. This is probably the most precise of all methods.

Here ‘compilerVersion’ parameter can be used as part of ‘build configuration’ to specify the version of the compiler that the plugin will use. However, you also need to set fork to true for this to work

Using the below ‘POM’ configuration, it is still possible to tell the ‘Maven Compiler Plugin’ the specific JDK to use during compilation. But such configuration will be specific to this plugin, and will not affect others.

<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>com.testoxide</groupId>
  <artifactId>maven-quick-start</artifactId>
  <version>1.0</version>
  
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <verbose>true</verbose>
          <fork>true</fork>
          <executable><!-- path-to-javac --></executable>
          <compilerVersion>1.3</compilerVersion>
        </configuration>
      </plugin>
    </plugins>
  </build>
 
</project>

4.3.1. Improvise – Use variable for Path

In the above ‘pom.xml’ snippet, rather than hardcoding the path to java compiler, you can replace it with a variable. We can do so by using the following property: <executable>${JAVA_1_4_HOME}/bin/javac</executable>

<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>com.testoxide</groupId>
  <artifactId>maven-quick-start</artifactId>
  <version>1.0</version>
  
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <verbose>true</verbose>
          <fork>true</fork>
          <executable>${JAVA_1_8_HOME}/bin/javac</executable>
          <compilerVersion>1.8</compilerVersion>
        </configuration>
      </plugin>
    </plugins>
  </build>
  
</project>

The best part of using the above property is that different users can specify their own values for this property in their ‘settings.xml’ file, keeping your project portable for different users and machine configurations.

<settings>
  [...]
  <profiles>
    [...]
    <profile>
      <id>compiler</id>
        <properties>
          <JAVA_1_4_HOME>C:\Program Files\Java\j2sdk1.4.2_09</JAVA_1_4_HOME>
        </properties>
    </profile>
  </profiles>
  [...]
  <activeProfiles>
    <activeProfile>compiler</activeProfile>
  </activeProfiles>
</settings>

4.3.2. Improvise – Pass args to compiler

If you wish to pass some arguments to the maven java compiler, you can do so in two ways.

Method 1: Using <configuration> element

You can pass the compiler arguments inside the ‘configuration’ part of the compiler plugin itself. A very common example is to pass min and max memory values as below.

Here we are passing the following arguments related to max and min memory to the compiler:

           <meminitial>128m</meminitial>
           <maxmem>512m</maxmem>

<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>com.testoxide</groupId>
  <artifactId>maven-quick-start</artifactId>
  <version>1.0</version>
  
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <verbose>true</verbose>
          <fork>true</fork>
          <executable>${JAVA_1_8_HOME}/bin/javac</executable>
          <compilerVersion>1.3</compilerVersion>
           <meminitial>128m</meminitial>
           <maxmem>512m</maxmem>
        </configuration>
      </plugin>
    </plugins>
  </build>
  
</project>

Method 2: Using explicit <compilerArgs>

You should use ‘<compilerArgs>’ element to pass specific compiler arguments that are not handled by the Compiler Plugin itself but are supported by the compilerId selected. For such arguments, use the Compiler Plugin’s <compilerArgs> parameter.

The following example passes compiler arguments to the javac compiler:

<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>com.testoxide</groupId>
  <artifactId>maven-quick-start</artifactId>
  <version>1.0</version>
  
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <verbose>true</verbose>
          <fork>true</fork>
          <executable>${JAVA_1_8_HOME}/bin/javac</executable>
          <compilerVersion>1.3</compilerVersion>
           <meminitial>128m</meminitial>
           <maxmem>512m</maxmem>
          <compilerArgs>
            <arg>-verbose</arg>
            <arg>-Xlint:all,-options,-path</arg>
           <arg>-Xmaxerrs</arg>
           <arg>1000</arg>
         <arg>-J-Duser.language=en_us</arg>
          </compilerArgs>
        </configuration>
      </plugin>
    </plugins>
  </build>
  
</project>

5. Custom Configuration Java 9 and Beyond

Starting from JDK 9, we can use a new command-line option i.e. ‘-release’ which is accepted by the javac executable and can be used to specify against which Java SE release you want to build the project.

This new argument replaces the traditional ‘source’ and ‘target’ properties used for Java 8 or earlier and will automatically configure the compiler to produce class files compatible with the given platform version which should be Java 9 or above. You can implement this ‘-release’ value in the following two ways :

5.1. Configure using POM Properties

In this method, you can specify the Java compiler version using the ‘maven.compiler.release’ element inside the POM Properties. Here is how the Maven Java compiler release element look inside pom properties:

<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>com.testoxide</groupId>
  <artifactId>maven-quick-start</artifactId>
  <version>1.0</version>
    <properties>
    <maven.compiler.release>11</maven.compiler.release>
  </properties>
</project>

5.2. Configure using plugin <configuration>

In this method, instead of the source and target properties (as mentioned in section 4.2 above), you need to use the ‘-release‘ property inside the Maven Java compiler plugin’s ‘<configuration>’ element. Given below is the snippet for such implementation:

<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>com.testoxide</groupId>
  <artifactId>maven-quick-start</artifactId>
  <version>1.0</version>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <release>11</release>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

The post Configuring Maven Compiler Plugin (Java) appeared first on Automation Dojos.

Maven project can be easily created using built-in plugins from the popular IDEs such as Eclipse and IntelliJ IDEA. However, in scenarios where you don’t or cannot use IDE, we can also create a maven project from the Maven native command line without using any IDE. In this article we would create a simple Java project using Maven command line with and without archetype.

Maven archetypes is a maven project templating toolkit which can be used to generate a skeleton maven project of different types, such as JAR, web application, maven site, etc. Once you create your project using one of the available archetype, you can easily tweak the generated project structure or artefacts including auto-generated pom.xml as per your project requirement.

The post How To Create Maven Project Using Command Line appeared first on Automation Dojos.

Table of Contents

• Design patterns Overview
• Introduction to Singleton Pattern
• Singleton Pattern Implementation
  • Eager Initialization
  • Lazy Initialization
  • Static block Initialization
• Advantages of Singleton
• Disadvantages of Singleton
• Conclusion

Design patterns Overview

Design patterns are basically solutions to programming problems that developers normally encounter during software development. Design patterns were first documented by four authors known as the Gang of Four (GoF).

Design patterns are broadly classified into creational, structural, and behavioral patterns. Creational patterns aid in object creation, structural patterns help to alter the structure of an object while behavioral patterns mostly have to do with algorithms.

Introduction to Singleton Pattern

Singleton is a creational design pattern; it helps in creating an object of a class. The Singleton pattern ensures that there is only one instance of a class. It is generally used for a class that consumes a lot of memory or one that uses expensive resources. Singleton ensures that there is only one instance of the class, thus saving on memory and other resources. The singleton pattern is mostly used for database connections, caching, logging, and other programming situations that mandate having a single object of a class.

Singleton Pattern Implementation

There are three main ways in which the singleton pattern can be implemented. All the approaches make use of a static instance, a private constructor, and a public getter method.

class MySingleton {
   private static MySingleton mySingleton = new MySingleton();
   private MySingleton() {
   }
   public static MySingleton getMySingleton() {
      return mySingleton;
   }
}

public class MySingleton {
private static MySingleton mySingleton;
   private MySingleton() {
   }
   public static MySingleton getMySingleton() {
      if (mySingleton == null) {
         mySingleton = new MySingleton();
      }
      return mySingleton;
   }
}

class MySingleton {
   private static MySingleton mySingleton;
   private MySingleton() {
   }
   
   static {
      mySingleton = new MySingleton();
   }
   public static MySingleton getMySingleton() {
      return mySingleton;
   }
   
}

Advantages of Singleton

There are several advantages of using a singleton class.  It helps it saving on memory and other resources by ensuring that there is only one instance of the class. It provides global access to the singleton instance. It gives a class control over the instantiation process.

Disadvantages of Singleton

The Singleton pattern has some disadvantages too. For one, singleton objects are often used as global variables which is against object-oriented principles like encapsulation. Secondly, singletons make unit testing difficult. A class that uses a singleton object cannot be tested by itself.

Conclusion

So, in this article, we understood the basics of the singleton design pattern. We also saw some of the ways in which you can implement the singleton pattern in Java. Finally, we understood some of the advantages and disadvantages of the singleton pattern.

The post How To Create Singleton Class in Java appeared first on Automation Dojos.