About Paris Apostolopoulos

Paris is a senior software engineer focusing on J2EE development, loves Business process modelling and is keen on software quality challenges. He is passionate about Java and Java communities. He is a co-founder and administrator of the first Java User Group in greece(JHUG.gr) and occasional speaker on meet-ups and seminars and regular blogger.

Java EE7 and Maven project for newbies – part 2 – defining a simple war for our application

Resuming from the first part

Part #1
We have just defined, our parent pom. A special type of pom that eventually defines the libraries that our application is going to use. It also configures all the maven tools used in order to package each module of our application. You can check out the part -1 sample code here.

So up until now in the directory where we will be developing our application we have a single folder called sample-parent and in this directory a pom.xml resides. Our parent pom!

CapturFiles_1

As we can see in the section modules, we have defined, the building blocks of our application

  • sample-ear
  • sample-web
  • sample-services
  • sample-domain

We need to create related maven modules and add the specific pom.xml files for each one of them.

Defining the war module

Under the sample-parent folder we create a sub-folder called sample-web and we also add a pom.xml file. (some people do it on the same level).

    <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>
      <parent>
        <groupId>gr.javapapo</groupId>
        <artifactId>sample-parent</artifactId>
        <version>0.0.1-SNAPSHOT</version>
      </parent>
      <artifactId>sample-web</artifactId>
    </project>

But this just nothing, we need to be more specific on what this pom will be helping us to builld, so we need to define the packing type, a name for the module (for this war) and any dependencies.

    ...
    <artifactId>sample-web</artifactId>
    <packaging>war</packaging>
    <build>
      <finalName>${project.artifactId}</finalName>
    </build>
     
    <dependencies>
      <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <scope>provided</scope>
       </dependency>
    </dependencies>
    </project>

In case you are using an IDE (e.g Eclipse) that supports Maven, it will automatically detect the changes on the content of your pom and will, create for you automatically folders, that conform with the Maven War packaging. It will create for you the following structure.  You can of-course do it on your own but, it is handy!

sample-web

  • src
    • main
      • java (add your java code here)
      • webapp (this is where WEB-INF\web.xml is placed)
      • resources (resources, like properties)
    •  test
      • java
      • resources

CapturFiles_2

Under the webapp subfolder I have already pre-created the \WEB-INF\web.xml file . I could skip this part because the maven plugin can do it for us, but just to show case that there cases where you want to create it on your own and any custom entries

CapturFiles_3

If you are wondering what to ‘put’ in an empty Servlet 3.1 web.xml file, then have a look here, or download the code for this post. I have also added in the java subfolder under a simple package a very simple Servlet, that is going to be included in our application. Just a few lines of code. Again you can download all the code in the related git (bitbucket) link, at the end of the post.
 

CapturFiles_6

So, we have added just a few lines on our war module pom file, and then in case we have an IDE, magically the tool created a very specific folder layout for us. We have ‘followed’ this layout and added a very simple servlet java class and a small xml descriptor. What is the real point here.

Well, the great thing about maven is that some of the stuff that our War module needs to built, are already defined and configured in the ‘special’ parent pom. But what are these stuff, and how Maven is going to use it? As we have already elaborated Maven is all about conventions. You put the right things in the ‘right’ way and then it does all the work for you.

So when maven scan(s) this war packing pom it will need to

  • compile our java class, which is a servlet
  • and package everything under the sample-web folder, into a war file + any dependencies.

Who is going to do all  of these things, since we have not added something special in our war pom( except the one dependency library). Well it is the configuration or our parent pom (see the previous post).

The maven-compiler-plugin is going to be ‘invoked’ in order to compile our sources, and since we have defined that the packaging of our maven module is ‘war’ then maven-war-plugin is going to invoked to package everything for us, create the appropriate descriptors.

So in a case where our application might have several war or jar modules, if we have a parent pom and we have defined in one central place the plugins and a basic configuration for then we DO NOT have to re-define it in all or our war / jar pom (s).

Only in case one of the war(s) or jar(s) need special treatment (e.g package something extra or have a special layout), then under the build section we could re-define the plugin and over-write or add some extra, behavior. But this not our case. We want our plugins to be defined, once, and have a common configuration that is going to be ‘inherited‘ by all the modules of our application that re going to use it.

Using the above hint, you can experiment and try, to create the sample-services module we have ‘defined’ above, or wait for the third part where we will quickly cover the rest of the concrete modules.

You can find the code for this post here. (post2 tag)

Resources

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


− 5 = one



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close