We can create a Maven project using our
IDE of choice. Eclipse works with Maven through an optional m2e
plugin, and NetBeans uses Maven as its native build system out of the box. If Maven is installed on a system, you could also choose to create the project from the command line:
mvn archetype:generate -DgroupId=com.packpub.hibernatesearch.chapter1 -DartifactId=chapter1 -DarchetypeArtifactId=maven-archetype-webapp
Time can be saved in either case by using a Maven archetype
, which is basically a template for a given type of project. Here,
maven-archetype-webapp
gives us an empty web application, configured for packaging as a WAR file. fieldsgroupId
and artifactId
can be anything we wish. They serve to identify our build output if we stored it in a Maven repository.
The pom.xml
Maven configuration file for our newly-created project starts off looking similar to the following:
<?xml version="1.0"?>
<project xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd"
xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<modelVersion>4.0.0</modelVersion>
<groupId>com.packpub.hibernatesearch.chapter1</groupId>
<artifactId>chapter1</artifactId>
<version>0.0.1-SNAPSHOT</version>
<packaging>war</packaging>
<name>chapter1</name>
<url>http://maven.apache.org</url>
<dependencies>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
</dependencies>
<build>
<!-- This controls the filename of the built WAR file -->
<finalName>vaporware</finalName>
</build>
</project>
Our first order of business is to declare which
dependencies are needed to compile and run. Inside the <dependencies>
element, let's add an entry for Hibernate Search:
... <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate-search</artifactId> <version>4.2.0.Final</version> </dependency> ...
Wait, didn't we say earlier that this was going to require over three dozen dependencies? Yes, that is true, but it doesn't mean you have to deal with them all! When Maven reaches out to a repository and grabs this one dependency, it will also receive information about all of its dependencies. Maven climbs down the ladder as deep as it goes, sorting out any conflicts at each step, and calculating a dependency hierarchy so that you don't have to.
Our application needs a database. To keep things simple, we will use H2 (www.h2database.com), an embeddable database system that fits in a single 1 MB JAR file. We will also use Apache Commons Database Connection Pools (commons.apache.org/dbcp) to avoid opening and closing database connections unnecessarily. These require declaring only one dependency each:
... <dependency> <groupId>com.h2database</groupId> <artifactId>h2</artifactId> <version>1.3.168</version> </dependency> <dependency> <groupId>commons-dbcp</groupId> <artifactId>commons-dbcp</artifactId> <version>1.4</version> </dependency> ...
Last but not least, we want to specify that our web
application is using version 3.x of the JEE Servlet API. In the following dependency, we specify the scope as provided
, telling Maven not to bundle this JAR inside our WAR file, because we expect our server to make it available anyway:
... <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <version>3.0.1</version> <scope>provided</scope> </dependency> ...
With our POM file complete, we can copy into our project those source files that were created earlier. The three Java classes are listed under the src/main/java
subdirectory. The src/main/webapp
subdirectory represents the document root for our web application. The index.html
search page, and its search.jsp
results counterpart go here. Download and examine the structure of the project example.