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
Leave a Reply