Thursday, May 01, 2014

Java EE7 and Maven project for newbies - part 2 - defining a simple war for our application #javaee #java #maven #juniordevs

Resuming from the first part  

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

Continue to part 3

References

No comments:

Post a Comment