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

May 1, 2014 java english
Share on:

Series

Previous Post, Next Post

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!

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) .

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.

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

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

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.

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 be invoked, in order to package everything for us.

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)

Continue to part 3

References