Creating a Maven Archetype from a #KFCStandard JavaFX Project

In this article I will discuss the creation of a Maven Archetype that my students or anyone else can use to begin developing a JavaFX application. Like so many adventures in programming this process began quickly and then bogged down in dealing with specific details. If you want to create your own archetype then this article will be helpful. Don’t forget to read the Sip of Whine section at the end.

The source code for the sample JavaFX project is at https://github.com/omnijava/SimpleJavaFX

The archetype folder ready for installation on your system is in the release of https://github.com/omnijava/ArchetypeJavaFX/releases

Step 1: Write a program

Archetypes can be created using either a bottom up or top down approach. By far the easiest approach is top down. You begin by writing a very simple Maven managed JavaFX application. You are providing a skeleton of an application that contains required or recommended packages, resources and source code.

The application I created is a simple JavaFX Stage with one Scene with a button that when pressed display some text. The code that delivers this experience is in the format that I want my students to follow. A few years ago some students created a hash tag to poke fun at my stringent rules, #KFCStandard. That I how I describe any rules or instructions that I provide to students that must be followed. This project exemplifies a number of #KFCStandards in the areas of pom files, how to start a JavaFX application, how to do unit testing and how to comment code. If you are not one of my students then you may have issues with my archetype. I would really like to hear your thoughts. Living in academia I worry that I loose site of the real world of software development.

Do your best to ensure that the program works. If you are creating an archetype where the files are empty waiting for the user to fill them in then this is likely not going to be a problem. If your code does something, as mine does, spend some time with it to get it right.

Archetype Tip #1: Always create packages that begin with the maven groupId and optionally the artifactId. This allows the user of your archetype to use their own package names.

Archetype Tip #2: If you reference the mainClass in the pom.xml as:

        <mainClass>com.kfcstandard.javafxarchetype.MainAppFX</mainClass>

Change it to

        <mainClass>${groupId}.${artifactId}.MainAppFX</mainClass>

Archetype Tip #3: If you need to have a package created when the archetype is used but you don’t have anything to place in the package then add an empty file. Maven will not create packages if there are no files in it.

pom.xml note: When I compile with NetBeans I get two warnings regarding the pom.xml. One tells me that ${groupId} is deprecated in favour of ${project.groupId} and the second tells me that ${artifactId} is deprecated in favour of ${project.artifactId}. The NetBeans 8.01 editor only recognizes ${project.groupId} and not the other. Therefore for now I am using the deprecated versions.

Step 2: Install Maven

I use NetBeans, my personal preference for an IDE and what I used in developing the archetype code. In one course that I teach I must use Eclipse. Both of these IDEs and others now provide good support for Maven. People who know me will now roll their eyes as I say that creating an archetype is easier to do at the command line. Download and install Maven from https://maven.apache.org/download.cgi. Read the install notes at https://maven.apache.org/install.html. You need to have Maven’s bin folder in the executable path and Windows users must have a JAVA_HOME environment variable.

Maven note: Some IDEs, such as NetBeans, contain the maven command line program. I recommend downloading Maven so that you are working with the most recent version.

Step 3: Clean up the project

Locate the folder your project is in. Delete everything in the project’s folder except for the src folder and the pom.xml file. You may want to make a copy of the project folder because you will be changing one file that will cause an exception to thrown if you run the project after the change.

Step 4: Alter the fxml file

If you are creating a project with an fxml file in the resources folder it likely contains a reference to its java controller file. In this project the file Scene.fxml contains:

fx:controller=”com.kenfogel.archetypejavafx.controllers.FXMLController”>

You need to replace the part of the package that matches the groupId and artifactId with the matching properties. The change looks like:

fx:controller=”${groupId}.${artifactId}.controllers.FXMLController”>

Step 5: Archetype Resolution or Generating the Archetype

Archetype Resolution is the term that the Maven developers use to describe using Maven to generate the archetype. This task will create a new target folder that contains the archetype version of your code.

Open a command window in the project’s root folder. In my case that is D:\mvnbuild\ArchetypeJavaFX. At the prompt issue the command:

mvn archetype:create-from-project

You may ignore all the warnings.

If all has gone well you will you will have the following folder that is not normally part of a Maven build:

D:\NetBeansProjects\javafxarchetype\target\generated-sources\archetype

Step 6: Make the fxml files filterable

The project in the archetype folder now contains two files named archetype-metadata.xml. This xml file determines which files will go into the archetype and whether or not they get filtered. To filter is to substitute a property with a value. That is why we changed the Scene.fxml file in the previous step. The archetype-metadata.xml files do not show that files in the fxml folder of resources are filterable. Locate these two files, mine are in:

D:\NetBeansProjects\javafxarchetype\target\generated-sources\archetype\src\main\resources\META-INF\maven

And

D:\NetBeansProjects\javafxarchetype\target\generated-sources\archetype\target\classes\META-INF\maven

Edit the files, they are identical, to change:

<fileSet encoding="UTF-8">
   <directory>src/main/resources</directory>
   <includes>
      <include>**/*.fxml</include>
      <include>**/*.css</include>
   </includes>
 </fileSet>

to read

<fileSet filtered="true" encoding="UTF-8">
   <directory>src/main/resources</directory>
   <includes>
      <include>**/*.fxml</include>
      <include>**/*.css</include>
   </includes>
</fileSet>

 

Step 7: Install the Archetype in your repository

Open a command window in your archetype folder and at the prompt enter the following commnd:

D:\NetBeansProjects\javafxarchetype\target\generated-sources\archetype>mvn install

Ignore any warnings. The archetype should be safely in

.m2\repository\com\kfcstandard\javafxarchetype-archetype

where ever your .m2 folder is.

Step 8a: Test if it works with the Maven command line

Create a new folder on your computer for the test. I created D:\mvntest. Open a command window in this folder. Run the command:

D:\mvntest>mvn archetype:generate -DarchetypeCatalog=local

What follows next is pretty straight forward. Here is my output. Notice that you need to enter the groupId, artifactId, version and package. The package should be made up from the groupId and artifactId.

[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-archetype-plugin:2.4:generate (default-cli) > generate-sources @ standalone-pom >>>
[INFO]
[INFO] <<< maven-archetype-plugin:2.4:generate (default-cli) < generate-sources @ standalone-pom <<<
[INFO]
[INFO] --- maven-archetype-plugin:2.4:generate (default-cli) @ standalone-pom ---
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
1: local -> com.kfcstandard:javafxarchetype-archetype (Standard starting point for JavaFX programs for students of Ken Fogel)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): : 1
Define value for property 'groupId': : com.squirrel
Define value for property 'artifactId': : moose
Define value for property 'version': 1.0-SNAPSHOT: :
Define value for property 'package': com.squirrel: : com.squirrel.moose
Confirm properties configuration:
groupId: com.squirrel
artifactId: moose
version: 1.0-SNAPSHOT
package: com.squirrel.moose
 Y: : y
[INFO] ----------------------------------------------------------------------------
[INFO] Using following parameters for creating project from Archetype: javafxarchetype-archetype:0.1
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: groupId, Value: com.squirrel
[INFO] Parameter: artifactId, Value: moose
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: package, Value: com.squirrel.moose
[INFO] Parameter: packageInPathFormat, Value: com/squirrel/moose
[INFO] Parameter: package, Value: com.squirrel.moose
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: groupId, Value: com.squirrel
[INFO] Parameter: artifactId, Value: moose
[INFO] project created from Archetype in dir: D:\mvntest\moose
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 30.660 s
[INFO] Finished at: 2015-09-01T20:48:04-04:00
[INFO] Final Memory: 13M/243M
[INFO] ------------------------------------------------------------------------
D:\mvntest>

In the project that has been created in the mvnbuild folder examine the Scene.fxml file and ensure that it has the path to the controller based on the groupId and artifactId you entered. Check out the pom.xml in the project and verify that the mainClass has the proper package.

Step 8b: Testing with NetBeans

 Start NetBeans and select:

File -> New Project

In the dialog choose Maven on the left and Project from Archetype on the right and click on Next.

01NewProject

Scroll down to find javafxarchetype-archetype, select it and click on Next.

02Archetype01

On the next screen you can fill in the Project Name that becomes the Artifact Id, the Group Id, and Version. It’s unusual to change the Package which defaults to Group Id plus Artifact Id.

02Archetype02

Click on Finish and you will a have a project loaded. You should be able to Clean and Build and then Run this project.

03Running

You are now ready to add your code to the project.

Step 8c: Testing with Eclipse

Start Eclipse and then choose File -> New -> Other. Open Maven in this dialog and select Maven Project.

04Eclipse01

There is nothing to change in the next dialog so just click on Next.

04Eclipse02

In the next dialog you should see all the archetypes available to Eclipse. On my system the local archetypes appear first so the archetype we created should be first. Select it and click on Next.

04Eclipse03

Now you can fill in the Group Id, Artifact Id, Version and Package. Like NetBeans the Package is made up of the Group Id and Artifact Id. Click on Finish.

04Eclipse04

The project will appear in the Package Explorer. Right mouse click on the project and choose Run As -> Maven Build and at the dialog just choose Run. The program should open. Close it and you are now ready to add your code to the project.

A Sip of Whine

In learning how to create a maven archetype I was confronted with a serious issue in regards to what I found on the web. Almost every blog, post or stackoverflow answer was nothing more than paraphrasing the Apache Maven documentation. It looks to me these authors have never used Maven or Archetypes in real world situations. The same holds true for the Apache Maven documentation. It lacks any real world examples and is far from being written in plain language.

There is also a bug in the Maven Archetype system. It took me two days to track it down. If you have a package made up of the groupId and artifactId in the src/main/java folder and you have the exact same package in src/test/java then the archetype will be damaged and will not work. The solution was to place the tests in a folder one level below the package. I will report it.

Email this to someoneTweet about this on TwitterShare on LinkedInShare on Facebook
Posted in Apache, Computer Science, Courses, Eclipse, Education, Java, Java 8, Java Fundamentals, Maven, NetBeans | Leave a comment

The #KFCStandard pom.xml file

The heart of a Maven managed project is the Project Object Model file named pom.xml. This determines what actions Maven will carry out. What follows is the pom file I require my students to use in their Software Development Project where they code a desktop application. A JEE version will be used in the next semester’s Web Development Project. Let’s look at this #KFCStandard pom.xml one section at a time.

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
               http://maven.apache.org/xsd/maven-4.0.0.xsd">

These first line is the XML declaration. The W3C states that the current version of XML is still 1.0 even though it is shown as the fifth edition. There may be a version 2.0 in the future. The encoding refers to the character set that is used in the document. UTF-8 is the most common form of encoding and it means that the document fully supports Unicode. The number 8 means that the supported character sets may consist of 8, 16, 32 or some other multiple of 8 bits to represent the characters of any language.

The next line contains the XML root tag named project. Following the tag are references to the namespace and schema used in the document. An XML validator uses this information to verify that the tags you use in the document are legal Maven pom tags.

    <modelVersion>4.0.0</modelVersion>

The modelVersion tag defines the version of the object model that the pom is using. It is required and as of Maven version 2.x it has been 4.0.0 and remains so for Maven 3.x

    <groupId>com.kenfogel</groupId>
    <artifactId>FXMavenDemo</artifactId>
    <version>1.0-SNAPSHOT</version>

These three tags make up the GAV. The groupId, artifactId and version taken together represent the unique name for the project. When you look at the dependency section you will see these tags and Maven uses them to locate the libraries you may need to add to your code. If your code becomes a dependency for another project then this is how you will identify it.

The groupId tag typically defines a package name although it can be any string of characters that adheres to the naming conventions for Java. Most organizations will use their company’s domain name reversed for the groupId and as the first part of all the packages their developers create. The artifactId follows the same Java naming conventions and is typically the name of the project.

The version tag defines the current version of the project. Whatever you place here will be appended to the JAR file that Maven creates. You are free to use any versioning scheme that you want such as 1.0.0 or Best Version Ever Mark 2. A common convention in versioning is to include either the string -SNAPSHOT to indicate a project under development or the string -FINAL to indicate a project in production.

    <packaging>jar</packaging>

The packaging tag tells us the format of the file that will be built. The choices are jar, war and ear.

    <name>FXMavenDemo</name>

The optional name tag allows us to associate a name with the build. This name can contain any characters including spaces.

 <description>A sample pom.xml file for this article</description>

The optional description tag lets you write any text that want to provide any information to someone reading this file.

<developers>
   <developer>
       <id>9999999</id>
       <name>Ken Fogel</name>
       <email>kfogel@anemailaddress.com</email>
   </developer>
</developers>

The developers tag and its child tags allow you to identify the members of a project.

 <organization>
     <!-- Used as the 'Vendor' for JNLP generation -->
     <name>Your Organization</name>
 </organization>

JNLP stands for Java Network Launch Protocol. It is used to enable Java applets or applications to be delivered via the web to a client computer. To be able to use this method of application delivery you must be able to sign your application with a valid certificate just like those used for SSL security for web transactions. If you are developing commercial Java applications then you will need to have a certificate.

If you are a student then use the name tag to show the school you are attending.

<properties>
    <project.build.sourceEncoding>
        UTF-8
    </project.build.sourceEncoding>
    <mainClass>
        com.kenfogel.fxmavendemo.MainApp
    </mainClass>
</properties>

The properties section allows you to declare variables that can be used in later sections of the pom. Within the properties tag you can make up any tag names you want.

${project.build.sourceEncoding}

Some plugins assume that the files are encoded in standard ASCII. In those cases they must be informed that the encoding is really UTF-8. This is not currently used in this pom example but is considered a tag to have just in case.

${mainClass}

There are two cases in this pom where a plugin needs to know the full path to the class file that contains the main method. The exec plugin needs to know where to start the program when it runs. The shade plugin must list the main class in the jar’s MANIFEST.MF file.

<dependencies>

The most significant function that Maven provides is the management of the required libraries for projects and having them available in the build path. In the dependencies section of a pom file you place a dependency block that must have the groupId, artifactId and version. When Maven process the pom file it will look for the files required for the dependency in the local Maven repository, the .m2 folder. If it’s not found here Maven will go online to the standard repository, maven.org, and use the information there to download the necessary files to .m2. If it cannot be found anywhere then an error will occur. Not every library can be located through maven.org so there is a repository tag that can be used in a pom if you wish to have Maven look in other online repositories. See http://bit.ly/1IlaoVx for more details on using multiple repositories.

<dependency>
   <groupId>org.slf4j</groupId>
   <artifactId>slf4j-api</artifactId>
   <version>1.7.12</version>
</dependency>
<dependency>
   <groupId>org.apache.logging.log4j</groupId>
   <artifactId>log4j-slf4j-impl</artifactId>
   <version>2.3</version>
</dependency>

<dependency>
   <groupId>org.apache.logging.log4j</groupId>
   <artifactId>log4j-api</artifactId>
   <version>2.3</version>
</dependency>
<dependency>
   <groupId>org.apache.logging.log4j</groupId>
   <artifactId>log4j-core</artifactId>
   <version>2.3</version>
</dependency>

This first block of dependencies defines the logging library we will use. There are two parts to this particular logging approach. The first two dependency blocks define the SLF4J or Simple Logging Framework for Java. This is a façade that provides an interface for logging that is independent from the specific implementation of a logging framework. The second two dependency blocks define log4J as the logging implementation. The version numbers here are very important as there is still a widely used version 1.x of log4j. Version 1.x will no longer be maintained and version 2.x is the new standard.

<dependency>
   <groupId>junit</groupId>
   <artifactId>junit</artifactId>
   <version>4.12</version>
   <scope>test</scope>
</dependency>

This is the dependency for the JUnit testing framework. It includes an additional tag named scope. This means that this dependency is only used during the test phase of the build. The JUnit jar will not be included in the executable shaded jar.

From this point on you can add any additional dependencies that you may need. Students in my courses almost always need MySQL.

<dependency>
   <groupId>mysql</groupId>
   <artifactId>mysql-connector-java</artifactId>
   <version>5.1.36</version>
</dependency>

Students in my third year project course also need Jodd Mail.

   <dependency>
      <groupId>org.jodd</groupId>
      <artifactId>jodd-mail</artifactId>
      <version>3.6.6</version>
   </dependency>

</dependencies>

The dependencies are complete and now we move on to the build.

<build>

The build section contains the information that Maven needs to compile, assemble and execute the project. Plugins define the operations needed to carry out these actions.

<defaultGoal>clean compile package exec:java</defaultGoal>

The tag defaultGoal is used to define the Maven goals, sometimes also called phases. Goals are actions that Maven must carry out. Most IDEs allow you to declare the goals that you want in their run command. If you do that then it will override what you see here. In this tag I have the most common goals.

Clean deletes all class files and jar files. If you use clean then you must close any running instance of your project. Clean deletes the target folder and then recreates it. Your code is run from the target folder so it cannot be deleted if a process is running somewhere from the folder.

Compile does just that. If you do not use clean first then only source code files newer than their compiled class files will be compiled. For small projects clean is not an issue but in large systems you will not necessarily clean for every compile.

Package means to create the JAR file. All the class files produced by the compile goal are added to the jar file. The default behaviour here is to not include dependencies in the jar.

Exec means to execute the program. There are two flavours of exec, one is exec:java and the other is exec:exec. You must use one of these. The exec:exec runs the packaged jar as if it were being run from the command line and in a separate Java Virtual Machine from the IDE and Maven. This will fail if the dependencies are not in the jar.

The exec:java runs the program from the compiled class files and not the jar within the same JVM as the IDE. The Maven dependencies are in the build path so they are available to the executing code. The exec:exec gives a better picture of how your code will perform on its own. On a slow machine exec:java will execute faster because a new instance of the JVM is not needed. One drawback to exec:exec is that logging messages or System.out messages will not appear in the IDE’s console until the program ends. Therefore I recommend exec:java during early development and exec:exec as you near the production release.

<plugins>

The plugins are the components of Maven that carry out the required tasks of the build. They look a lot like dependencies and require code downloaded from a repository if not already in your .m2 repository.

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-compiler-plugin</artifactId>
   <version>3.3</version>
   <configuration>
      <source>1.8</source>
      <target>1.8</target>
      <compilerArgument>-Xlint:all</compilerArgument>
      <showWarnings>true</showWarnings>
      <showDeprecation>true</showDeprecation>
   </configuration>
</plugin>

The Maven Compiler plugin is responsible for executing the javac compiler on your code. This means that when using an IDE it is Maven and not the IDE that compiles the code. The configuration tag defines some parameters for the compiler. The first two, source and target, defines the format of the .java files and the format of the .class files. It therefore defines the major version of the compiler which in this example is 1.8.

The tag compilerArgument adds the string to the compiler execution such as javac –Xlint:all. This means that we want the messages that the compiler generates to be available. It does not mean that they will be displayed. That is the role of the next two tags, showWarnings and showDeprecation.

<plugin>
   <groupId>org.apache.maven.plugins</groupId>
   <artifactId>maven-shade-plugin</artifactId>
   <version>2.4.1</version>
   <configuration>
      <transformers>
         <transformer implementation=
                 "org.apache.maven.plugins.shade.
                     resource.ManifestResourceTransformer">
            <mainClass>${mainClass}</mainClass>
         </transformer>
      </transformers>
   </configuration>
   <executions>
      <execution>
         <phase>package</phase>
         <goals>
            <goal>shade</goal>
         </goals>
      </execution>
   </executions>
</plugin>

This is the Shade plugin. It is responsible for creating an executable jar file. To be a standalone executable jar there are two changes that have to be made to a basic jar. The first is to include all the dependencies in the jar. The second is to create a text file called MANIFEST.MF in the META_INF folder in the jar that contains the name of the class where the main method is found. The execution of shade is defined in the executions tag to occur as part of the package phase when the plain jar is made. You will end up with two jars when this is done. The original and the executable. The following image gives you a sense of the difference between a plain jar and and an executable or shaded jar.

jar

<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>exec-maven-plugin</artifactId>
   <version>1.4.0</version>
   <executions>
      <execution>
         <id>default-cli</id>
         <goals>
            <goal>exec</goal>
            <goal>java</goal>
         </goals>
         <configuration>
            <mainClass>${mainClass}</mainClass>
            <executable>${java.home}/bin/java</executable>
            <commandlineArgs>-jar ${project.build.directory}/
               ${project.build.finalName}.jar</commandlineArgs>
         </configuration>
      </execution>
   </executions>
</plugin>

The exec plugin defines how the program will be run. As there are two ways to run a program, exec:exec and exec:java they are both defined here. The executable tag defines where the java virtual machine, either java.exe or javaw.exe, can be found. The commandlineArgs defines what is added to the JVM to run the executable jar in a separate JVM.

If you are using exec:java then the mainClass tag is used to identify which class file contains the main method.

The values for all the $ values except ${mainClass}, that was defined in properties, are provided by the IDE.

         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.18.1</version>
            <configuration>
               <skipTests>false</skipTests>
            </configuration>
         </plugin>
      </plugins>
   </build>
</project>

The last plugin at the end of the pom file is Surefire. It runs the JUnit tests and then writes the results of the text to a text file and an xml file. These results can also be seen in the console. There is one configuration and that is to skipTests. Set this true with caution as forgetting to set it back to false may result in delivering code you think works but really does not.

A complete pom follows. It comes from the sample project my students in my first class must run. It is commented throughout. If you want to learn more about the pom visit http://maven.apache.org/pom.html

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

   <!-- Maven version of the xml document currently only 4.0.0 is valid -->
   <modelVersion>4.0.0</modelVersion>

   <!-- The GAV consists of an arbitrary descriptor that is usually in the form of a reverse domain name. -->
   <groupId>com.kenfogel</groupId>

   <!-- This is the name given to the packaged build -->
   <artifactId>FishFXTable</artifactId>

   <!-- The version of the build. Any value is valid though a number and a string are common. SNAPSHOT means a project under development. FINAL is commonly used to refer to stable production version -->
   <version>1.0-SNAPSHOT</version>

   <!-- Default value is jar but may be war or ear -->
   <packaging>jar</packaging>

   <!-- The name given to the project. Unlike groupId and artifactId a name may have spaces -->
   <name>FishFXTable</name>

   <!-- A description of the program -->
   <description>JavaFX TableView example based on JDBCDemo</description>

   <!-- Identifies the programmer or programmers who worked on the project -->
   <developers>
      <developer>
         <id>9999999</id>
         <name>Ken Fogel</name>
         <email>kfogel@anemailaddress</email>
      </developer>
   </developers>

   <!-- The company or organization that the programmer(s) work for -->
   <organization>
      <name>Dawson College</name>
   </organization>

   <!-- Global settings for the project. Settings can be accessed in the pom by placing the tag name in ${...} ex. ${mainClass} -->
   <properties>
      <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>

      <!-- class that has the main method -->
      <mainClass>com.kenfogel.fishfxtable.MainAppFX</mainClass>
   </properties>

   <dependencies>

      <!-- The dependency for the SLF4J Facade -->
      <dependency>
         <groupId>org.slf4j</groupId>
         <artifactId>slf4j-api</artifactId>
         <version>1.7.12</version>
      </dependency>
      <!-- Binding for Log4J -->
      <dependency>
         <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-slf4j-impl</artifactId>
         <version>2.3</version>
      </dependency>
      <!-- Logging Framework Dependency Uses the log4j2 library -->
      <dependency>
         <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-api</artifactId>
         <version>2.3</version>
      </dependency>
      <dependency>
         <groupId>org.apache.logging.log4j</groupId>
         <artifactId>log4j-core</artifactId>
         <version>2.3</version>
      </dependency>

      <!-- JUnit 4 testing dependency -->
      <dependency>
         <groupId>junit</groupId>
         <artifactId>junit</artifactId>
         <version>4.12</version>
         <!-- only to be used during test phase will not be included in executable jar -->
         <scope>test</scope>
      </dependency>

      <!-- MySQL dependency -->
      <dependency>
         <groupId>mysql</groupId>
         <artifactId>mysql-connector-java</artifactId>
         <version>5.1.36</version>
      </dependency>

      <!-- Jodd Mail Dependency -->
      <dependency>
         <groupId>org.jodd</groupId>
         <artifactId>jodd-mail</artifactId>
         <version>3.6.6</version>
      </dependency>

   </dependencies>

   <build>
      <!-- Goals may be set in the IDE or the pom IDE or CLI goals override the defaultGoal -->
      <defaultGoal>clean compile package exec:java</defaultGoal>

      <!-- Plugins define components that perform actions -->
      <plugins>

         <!-- Compiler: Select the version of the Java compiler and any command line switches to use with it -->
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.3</version>
            <configuration>
               <!-- Java version of the source files -->
               <source>1.8</source>

               <!-- Java version of the class files -->
               <target>1.8</target>

               <!-- sometimes the IDE does not reveal all the important warnings -->
               <compilerArgument>-Xlint:all</compilerArgument>
               <showWarnings>true</showWarnings>
               <showDeprecation>true</showDeprecation>
            </configuration>
         </plugin>

         <!-- Shade: Create an executable jar containing all the dependencies when the package goal is carried out -->
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-shade-plugin</artifactId>
            <version>2.4.1</version>
            <configuration>
               <transformers>
                  <transformer implementation="org.apache.maven.plugins.shade.resource.ManifestResourceTransformer">
                     <mainClass>${mainClass}</mainClass>
                  </transformer>
               </transformers>
            </configuration>

            <executions>
               <execution>
                  <phase>package</phase>
                  <goals>
                     <goal>shade</goal>
                  </goals>
               </execution>
            </executions>
         </plugin>

         <!-- Exec: Executes the program -->
         <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>exec-maven-plugin</artifactId>
            <version>1.4.0</version>
            <executions>
               <execution>
                  <id>default-cli</id>
                  <goals>
                     <!-- Runs in separate instance of JVM -->
                     <goal>exec</goal>
                     <!-- Runs in same instance of JVM as Eclipse -->
                     <goal>java</goal>
                  </goals>
                  <configuration>
                     <!--used by java goal -->
                     <!--executes in the same VM that Maven runs in -->
                     <mainClass>${mainClass}</mainClass>

                     <!--used by exec goal -->
                     <!--runs in a separate VM from the one that Maven runs in -->
                     <executable>${java.home}/bin/java</executable>
                     <commandlineArgs>-jar ${project.build.directory}/${project.build.finalName}.jar</commandlineArgs>
                  </configuration>
               </execution>
            </executions>
         </plugin>

         <!-- Surefire: During the test phase of the build life cycle executes JUnit tests and write the results to an xml and txt file -->
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.18.1</version>
            <!-- Turn on tests: false, Turn off tests: true -->
            <configuration>
               <skipTests>false</skipTests>
            </configuration>
         </plugin>

      </plugins>
   </build>
</project>

 

Email this to someoneTweet about this on TwitterShare on LinkedInShare on Facebook
Posted in Computer Science, Courses, Java, Maven, pom.xml | Tagged | Leave a comment