Last installment we started looking at how we organized our J2EE project structure and described it with Maven. Now we'll continue looking at the project's structure.
One of the locations that Maven expects to find in a project is the directory where the source of the project goes. This is defaulted to src. The src folder should go in the root of the project alongside the pom.xml.
Inside src is a directory for the main source of the project, called main. At the same level is a folder for test code, called test. The code goes in the main and test directories and is organized by the type of language—in this case, a java directory holds the Java code in the data project directory, and a java and flex directory in the web project.
At that level in the data project will also be an src/main/resources directory to contain any configuration files or artifacts that need to be packaged along with the build, and an src/test/resources directory for anything needing inclusion during the test phase of the build. Anything included from these directories will be in the root of the classpath at these phases.
In the web project, we’ll have a directory called bookie.war to hold the contents of the WAR archive that aren’t compiled, like the java and flex will be. As I mentioned, web archive files have a specified structure with certain files that need to be included in certain places. There should be a WEB-INF directory in the root which contains a file named web.xml, which describes the deployment of the archive. All the compiled Java files go in a directory called classes in WEB-INF, and any Java libraries go in a directory called lib. Maven will create these directories later. Anything we want to be in the root of the WAR, we can put in this bookie.war directory.
The web archive, when deployed, will contain the compiled Flex application. It’s also where the code for LCDS goes. Inside the bookie.war directory, in the WEB-INF directory, you’ll find a directory called flex. This contains all the resources needed to run LCDS.
Another important directory is src/main/data, which is in the data project and stores the descriptions of the database schema and the test data we’ll want in the database during automated Java tests. This is a non-standard directory, but it makes sense to put these resources here. One more non-standard directory is a server-config directory to store—you guessed it—server configuration information. Let’s organize this by server, so we’ll have a jboss directory for the server configuration for our target server environment.
I say these directories are non-standard because they aren’t specified by Maven, but the configuration files in there don’t belong in, say, the standard “resources” directory because we don’t want them included in the JAR or WAR. I supposed I could have put them somewhere like src/server-config, but I went with server-config off the root of the project to make it explicit.
The project to combine the persistence unit, the “data” project, and the user interface “ui” project into an .ear is called bookie-ear. We’ll have a separate pom.xml there to control how Maven builds the enterprise application.
<project ...>
<modelVersion>4.0.0</modelVersion>
<parent>
<artifactId>bookieProject</artifactId>
<groupId>lcds.examples.bookie</groupId>
<version>1.0-SNAPSHOT</version>
</parent>
<groupId>lcds.examples.bookie</groupId>
<version>1.0-SNAPSHOT</version>
<artifactId>bookie-ear</artifactId>
<packaging>ear</packaging>
<name>Bookie Example EAR Project</name>;
This part of the POM looks a lot like the parent POM. First the POM references the parent project in the “parent” tags to let Maven know that this project doesn’t stand alone. Just like anywhere else, projects are identified by artifactId, groupId, and version. Here are the .ear project’s settings for those attributes:
<finalName>bookie</finalName>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-ear-plugin</artifactId>
<version>2.3</version>
<configuration>
<modules>
<jarModule>
<groupId>lcds.examples.bookie</groupId>
<artifactId>bookie-data</artifactId>
<bundleDir>/</bundleDir>
<includeInApplicationXml>true</includeInApplicationXml>
</jarModule>
<webModule>
<groupId>lcds.examples.bookie</groupId>
<artifactId>bookie-ui</artifactId>
<contextRoot>/bookie</contextRoot>
<unpack>true</unpack>
</webModule>
</modules>
</configuration>
</plugin>
</plugins>
</build>
Next, the build section tells Maven that the final name of the artifact should be “bookie” instead of the more cumbersome version containing the “1.0-SNAPSHOT”. Then we configure the EAR plug-in, the thing that builds EAR files, to tell it we want the bookie data project put in the root of the EAR and included in the generated application.xml file.
Also, we tell Maven that we want to include the web app project, bookie-ui as a web archive, that the contextRoot should be /bookie, and that we want the WAR unpacked or “exploded.” You can change that setting once you get ready for deployment, but I don’t know of any easy way to automate the process of choosing which environment you’re in, and whether to unpack in that environment.
<dependency>
<groupId>lcds.examples.bookie</groupId>
<artifactId>bookie-data</artifactId>
<version>1.0-SNAPSHOT</version>
</dependency>
<dependency>
<groupId>lcds.examples.bookie</groupId>
<artifactId>bookie-ui</artifactId>
<type>war</type>
<version>1.0-SNAPSHOT</version>
</dependency>
</dependencies>
</project>
This next section tells Maven on which other projects this project depends. This is what starts all that dependency management magic I talked about before. The EAR project is just there to get our JAR and WAR together in one place for easy deployment, so it only has those projects as dependencies.
Next in the series we'll have a look at the Maven project lifecycle. You can always find the entire series here.