Java7
Posts tagged dependency management
A Practical Introduction To Maven
Jan 8th
Few months ago, i have written an article on how to install Maven on Linux here. While i am also trying to write a guide on doing so on Windows, let me first show you a few good features of Maven 3.
The guide below walks through some Maven key commands, it is unlikely that you will configure by hand, but it is essential to know Maven’s workings through some plain command lines. For example, you may like to know that certain project dependency management features may be made through a Java IDE such as Eclipse. Discover how here http://java.sg/revolutionize-the-way-you-create-anymore-new-java-applications-with-maven-3-0/.
mvn archetype:generate
$ mvn archetype:generate
This command gives us a Maven maintained list of archetypes available for use. The result list of this command is quite long.
bash-3.2$ mvn archetype:generate
[INFO] Scanning for projects...
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
[INFO]
[INFO] >>> maven-archetype-plugin:2.0:generate (default-cli) @ standalone-pom >>>
[INFO]
[INFO] <<< maven-archetype-plugin:2.0:generate (default-cli) @ standalone-pom <<<
[INFO]
[INFO] --- maven-archetype-plugin:2.0:generate (default-cli) @ standalone-pom ---
[INFO] Generating project in Interactive mode
[INFO] No archetype defined. Using maven-archetype-quickstart (org.apache.maven.archetypes:maven-archetype-quickstart:1.0)
Choose archetype:
1: remote -> docbkx-quickstart-archetype (-)
3: remote -> simple (-)
6: remote -> gquery-archetype (-)
16: remote -> vaadin-archetype-widget (This archetype generates a Vaadin widget project for Vaadin 6.2+ and a test application.)
17: remote -> android-quickstart (Creates a skeleton for an Android application)
98: remote -> maven-archetype-quickstart (An archetype which contains a sample Maven project.)
168: remote -> struts2-archetype-blank (-)
204: remote -> appfuse-core-archetype (-)
238: remote -> ear-javaee6 (Archetype for EAR package using Java EE 6)
362: remote -> javg-minimal-archetype (-)
Choose a number: 98:
For the focus of keeping this guide short and purposeful, i have omitted the full results of the archetype listing to show you only some of the common project archetypes you will come across. The number representing each archetype is not a permanent fixture of the archetype but a ordering that is subjected to change.
maven-archetype-quickstart
We are particularly interested in the maven-archetype-quickstart archetype for generating us a simple Java J2SE application.
Choose a number: 98: 98
So when asked to select a number representing the archetype from the list, we key in 98, and notice that by default Maven displays in the prompt the default archetype, this is especially useful for new comers.
Define value for property 'groupId': : sg.java
Define value for property 'artifactId': : helloworldMaven
Define value for property 'version': 1.0-SNAPSHOT: : 1.0-SNAPSHOT
Define value for property 'package': sg.java: : sg.java
Next, Maven asks us to define values for the group id, artifact id, version, and package strategy that we would be employing.
groupId
group id is the unique identifier that will differential this project from another. It is most commonly represented in dot notation (sg.java.maven). For example, if i worked in SCS limited, then my group id would be com.scs, and sg.java for my own personal projects. This requirement is not restrictive, and you certainly may choose to break off the convention, just as JUnit does not follow the dot notation.
However, it is best to follow the dot notation, and represent your project in an entity manner. See this article for such reason why we should so. http://java.sg/use-sun-java-packaging-convention-please/
artifactId
artifact id is the name of the project you want it to be known by. This name differentiates one project from another you create. For example, if you a constructing an integrated billing management system, it makes sense to abbreviate the long name to “ibms”, and thereafter using it as your artifactId.
As the artifact id forms part of your packaging strategy by default, and recommended, it is best to choose a short artifact id so that you package does not become excessively long.
version
Chances are that if you not writing an API or a library, then you may not be concerned with the overall naming strategy of the project over time and change. Certainly, jasper reports would not want to be known as jasper reports “the beginning”, jasper reports “the prelude”, and jasper reports “the finale” for each version change. Therefore, version is subjective to the incarnation of the project and allows each “version” to keep its name but well differentiated by a meaningful version number, i.e. JUnit 1.0, JUnit 2.0.
Confirm properties configuration:
groupId: sg.java
artifactId: helloworldMaven
version: 1.0-SNAPSHOT
package: sg.java
Y: : Y
[INFO] ----------------------------------------------------------------------------
[INFO] Using following parameters for creating project from Old (1.x) Archetype: maven-archetype-quickstart:1.1
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: groupId, Value: sg.java
[INFO] Parameter: packageName, Value: sg.java
[INFO] Parameter: package, Value: sg.java
[INFO] Parameter: artifactId, Value: helloworldMaven
[INFO] Parameter: basedir, Value: C:\
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] ********************* End of debug info from resources from generated POM ***********************
[INFO] project created from Old (1.x) Archetype in dir: C:\helloworldMaven
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1:04.715s
[INFO] Finished at: Sat Jan 08 18:10:33 SGT 2011
[INFO] Final Memory: 9M/150M
[INFO] ------------------------------------------------------------------------
bash-3.2$
Maven asks us to confirm the properties, and once we do, it outputs more verbose text. It ends by generating the actual project in the file system. You may look for the Maven generated artifact sitting in your local file system in the same directory when issuing the mvn archetype:generate command.
bash-3.2$ pwd
/cygdrive/c
bash-3.2$ ls
$Recycle.Bin Program Files Users csvn hiberfil.sys install.res.1036.dll pagefile.sys
Documents and Settings Program Files (x86) VC_RED.cab dell install.exe install.res.1040.dll splash.idx
Intel ProgramData Windows drvrtmp install.ini install.res.1041.dll vcredist.bmp
MSOCache Recovery bea dvmaccounts.ini install.res.1028.dll install.res.1042.dll
Oracle System Volume Information c globdata.ini install.res.1031.dll install.res.2052.dll
PerfLogs Temp c3 helloworldMaven install.res.1033.dll install.res.3082.dll
bash-3.2$
I am actually working on a Windows system, and using cygwin and mintty to emulate a unix environment (this is really a personal preference, having worked in a data center for a year and a half, i grew very customized to looking at prompts).
As you may see from the above, i did a pwd (present working directory) to see where am i, i am located in the C:\ directory, and notice the “helloworldMaven” directory from the listing? That is the project artifact that Maven had us configured earlier and generated for us.
bash-3.2$ cd helloworldMaven/
bash-3.2$ ls
pom.xml src
bash-3.2$ cd src
bash-3.2$ ls
main test
bash-3.2$ cd main
bash-3.2$ ls
java
bash-3.2$ cd java
bash-3.2$ ls
sg
bash-3.2$ cd sg
bash-3.2$ ls
java
bash-3.2$ cd java/
bash-3.2$ ls
App.java
bash-3.2$ pwd
/cygdrive/c/helloworldMaven/src/main/java/sg/java
bash-3.2$
Traverse through the folders, and you may find the exact behavior of our configuration.
Lets see what the pom.xml file contains.
bash-3.2$ cat pom.xml
<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>sg.java</groupId>
<artifactId>helloworldMaven</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>jar</packaging>
<name>helloworldMaven</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>
bash-3.2$
You may have noticed that the pom.xml included the dependencyfor junit 3.8.1. This is because that the archetype we selected (maven-archetype-quickstart) contains some examples of a normal Java project. And quite often does enterprise projects require us to have unit tests. If you are uncomfortable with it being there, you may remove the dependency. When you do so, also remove the test folder and its contents as there is a Java file (AppTest.java) inside that depends on junit libraries.
Thats all
You may now use the project artifact for development. :) Cheers.
If you continue to navigate through the project folder “helloworldMaven”, you will notice some more folders and files generated also by Maven.
Because the list of available archetypes change from time to time, just as the list maintained by yellow dog update modifier (yum CentOS / RHEL), it is not recommended to keep a “list of archetypes” cheat sheet as the preferred discovery way would be through archetype:generate.
What is a Maven Archetype?
An archetype in Maven terminology is a project terminology package and structure templating toolkit. It defines a set of standard of how some projects manage their initial structures. For example, Java EE web projects, and EJB projects both have its unique way of structuring certain folders and the placement of certain files. Maven allows us to create commonly used “ready” projects that we may base off for development in the quickest way.
Reference
Introduction to Maven Archetype http://maven.apache.org/guides/introduction/introduction-to-archetypes.html
Definition of Archetype http://dictionary.reference.com/browse/archetype
Project Object Model http://maven.apache.org/pom.html
Revolutionize the way you create anymore new Java applications – with Maven 3
Jan 2nd
Make a vow, that from 2011 you will not build by hand, you will not manually manage dependencies. You will, use Maven tool.
When i started out listening in parts of what Maven is from various sources, i simply did not pay attention or try to understand what its goal is. And its a true pity that, yes, Maven is more than dependency management – the team has been trying to sell Maven in its full entirety that the people (developers) are so “scared” to get started out with it. And frankly not all developers like changes. (frequent and rapid change that is)
Lets put a stop to this and help all developers and organizations save that effort and money spent on dependency management respectively.
What are the odds that your web / j2se / connector application isn’t using any third party libraries? And by that i mean anything which you needed to manually configure to your build path, by hand or by ant. Those have been hacks that have been working till Maven came up with this beautiful solution.
Consider this, when your application requires say Spring framework libraries, core and bean. Normally without Maven tool, one would download to a local directory, write some ant line so that ant may compile and build, then also set up the build path on Eclipse (assuming that is the IDE you are working on), and repeatedly perform this for every library you require.
This is not so a problem because you are already familiar, and the odds are there that you have done this not in one sitting, rather each time you realize you need something (a library), you search for and put it in use your project using the above manner.
What if, you are working on a team, or what if you are expecting turnovers, or simply new head counts? Well these are the people who come in, spend a day or two trying to figure out the dependencies to add in order to take away all the build errors from Eclipse, playing the guessing game on which version you were using, and bingo, that is money wasted, and the least surest way of building an enterprise application – by chancing with dependency versions.
Lets highlight how to get started with Maven, and assuming we are on the Eclipse IDE page:
1- Download the standard Eclipse EE version. (Skip if you already have one).
2- Install the Maven for Eclipse IDE plugin directly from your IDE. http://m2eclipse.sonatype.org/installing-m2eclipse.html Eclipse Update Site
3- Create a new Maven project using the wizard.
4- Volah, your project dependency is now fully managed by Maven.
5- Lets take this a step forward by adding Spring library dependency using Maven. Right click on the project created in the previous step, navigate to and select “Add Dependency” from the context menu.
6- Type “Spring” into the text field and wait for the list of dependency appear. Select 3.0.5 release, which is what we are going for right now. Notice that once you do so, Maven downloads the required files, and actually caches on your local directory so that the next time you request for the same dependency, it loads from locally.
7- Once it is done, expand the “Maven Dependencies” tree to discover the Spring libraries it has just downloaded and linked for us. Subsequently, we will only need to go through the same step to add another dependency, such as libraries from Apache Commons.
Thats all for Maven for now, and hopefully it gets you started and excited about a whole new paradigm of project source and build dependency management.
