• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer
  • Core Java
  • Design Patterns
  • JSP
  • Servlets
  • Building Tools
  • jQuery
  • Spring
  • Hibernate
  • Mongo DB
  • More
    • HTML
    • SCJP
    • AJAX
    • UML
    • Struts
    • J2EE
    • Testing
    • Angular JS

J2EE Reference

  • Home
  • About Us
    • Java Learning Centers
  • Contact Us

Maven Archetypes and pom.xml

July 22, 2015 By j2eereference Leave a Comment

Maven Archetypes

The advantage of using Maven is that, it does a lot of things behind the scenes. We don’t have to configure each and every step – creating the source code directories, configuring the dependencies, compiling and packaging etc.

Project Template:

Once we download and configure maven in development environment, we start off with configuring the project structure using maven.
From the Project folder in command prompt, we run below command to set up the project.
mvn archetype:generate
When we run this command, it creates the folder structure and pom.xml. This is downloaded from the maven repository depending the inputs we provide. The inputs that we provide for ‘mvn archetype:generate’ are:

1. Archetype : This is the information to Maven as to what is the kind of project we need. Maven has a huge list of archetypes. Each archetype corresponds to a particular type of application that we want to develop. It decides the layout of the files, the folder structure and the dependencies that are required. Each archetype is a good starting point for the type of application we want to build.

2. Group ID : It is an explanatory ID that we give to group all the  artifacts. It is analogous to package structure. For example : com.org. j2eereference

3. Artifact ID : Identifies the output that project generates. If it is web app, it would be a war file. If it is an enterprise app, it would be an ear file. It is analogous to the  name of the jar/war/ear that we want to create.

4. Version : The version of the application. When we are starting the application, we normally keep the default value of 1. With different releases of the application, this version number keeps increment.

5. Package : The name of the package where we need to place our source code. It is an information to maven as to what package a particular class belongs to. Depending the input we provide here, a particular java class will be assigned to the package.

Build:

All the information that we provide as input to archetype (group id, artifact id, version, package) will be available in pom.xml

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
<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>
 
  <groupId>com.org.j2eereference</groupId>
  <artifactId>MavenTestApp</artifactId>
  <version>1.0-SNAPSHOT</version>
  <packaging>jar</packaging>
 
  <name>MavenTestApp</name>
  <url>http://maven.apache.org</url>
 
  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>
 
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

We have a sample pom.xml that was generated when we ran ‘mvn archetype:generate’.

  • Notice that we have groupId, artifactId and version in the pom.xml which are the keys for any particular artifact. If we have an artifact and want to publish it to a repository, Maven identifies the artifact using the combination of these 3 keys.
  • We also have a packaging tag which tells Maven what is the actual output – a jar or war or an ear. In the example, it is a jar and this again depends on archetype. If we had chosen archetype for a web application, this would probably be a war.
  • name tag specifies the name of the application.
  • properties tag tells that the source code encoding is UTF-8
  • Now have a look at the dependencies tag. <dependencies> will have the list of all the dependencies, each specified inside a <dependency> tag. In the example, there is only one dependency, i.e., junit. To specify the dependency, we again use the combination of groupId, artifactId and version. Say for example, junit releases a new version. The version number would change to, say 3.8.2. The groupId and artifact would remain same and to refer to the newer version, we only need to update the version number. Suppose we want to use a different artifactId for the same groupId, we would change the artifactId to whatever artifactId and update the version as accordingly.

So, the structure is like a tree, where groupId is the highest level which has lots of artifacts inside it. We can choose the right artifact by mentioning the artifactId and the version of the artifact.

Scope is something that tells when to use the particular artifact (will be detailed in upcoming posts). This is used by Maven when building and packaging the application.

This is how maven uses gruopId, artifactId and version to pull up an artifact from the repository.

Now the below code should make sense.

1
2
3
<groupId>com.org.j2eereference</groupId>
  <artifactId>MavenTestApp</artifactId>
  <version>1.0-SNAPSHOT</version>

Our groupId, artifactId and version number should be in such a way that other applications can consume our artifact if we choose to release this and save it in a repository. This is applicable for other reasons as well. Suppose we do not choose to publish in an online repository but going to use it for internal consumption. For that, Maven has an internal repository on the local machine itself. Whenever we build and package any artifact, maven installs the artifact into the local repository.  Suppose we have a different web application that uses this jar (MavenTestApp-1.0-SNAPSHOT.jar in the example), all we need to do is, in the pom.xml of that application, we need to add the dependency for this jar.

1
2
3
4
5
<dependency>
<groupId>com.org.j2eereference</groupId>
  <artifactId>MavenTestApp</artifactId>
  <version>1.0-SNAPSHOT</version>
</dependency>

What Maven does is, it will first look in the local repository for this jar and check if such an artifact is available. If it available, Maven will pull it up from local repository. If it is not available, it will go to the online repository.

This is the main information available in pom.xml

1. maven co-ordinates : artifactId, groupId, version etc

2. meta data : name and version of the project

3. Build information : says the project is jar, war or an ear

4. Resources and dependencies : the resources and dependencies required to successfully build the project

Related Posts

  • A Web Application Using Maven in Eclipse IDE
  • Adding dependency in Maven
  • Maven Build Phases

Filed Under: Building Tools Tagged With: archetype, Maven, pom

Reader Interactions

Leave a Reply Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

FOLLOW US ONLINE

  • View J2eereference-166104970118637’s profile on Facebook
  • View j2eereference’s profile on Twitter
  • View j2eereference’s profile on LinkedIn

Subscribe by email

Recent posts

  • Java Buzzwords
  • Anonymous Inner Class in Java
  • Network Programming – java.net Package
  • Java Regular Expressions
  • Method Local Inner Class in Java
  • URL Processing in Java
  • Iterator Design Pattern Implementation using Java
  • Strategy Design Pattern Implementation using Java
  • Decorator Design Pattern
  • Adapter Design Pattern Implementation using Java
  • JSF Composite Components
  • JSF UI Components
  • What is JavaServer Faces (JSF)?
  • GOF Design Patterns
  • History and Need for Design Patterns

Footer

Core Java
Design Patterns
JSP
Servlets
HTML
Building Tools
AJAX
SCJP
jQuery
Testing
Spring
UML
Struts
Java Centers
Java Training
Home
About Us
Contact Us
Copyright © j2eereference.com. All right reserved.