Multi module projects work in eclipse by doing the following…

Specify the server runtime environment

Include the Server run-time environment in the web project’s pom.xml file. For example for tomcat
Inside the build section of the pom put in the following.

<plugin>
	<groupid>org.apache.maven.plugins</groupid>
	<artifactid>maven-eclipse-plugin</artifactid>
	<configuration>
		<downloadsources>true</downloadsources>
		<downloadjavadocs>true</downloadjavadocs>
		<wtpapplicationxml>true</wtpapplicationxml>
		<wtpversion>1.5</wtpversion>
		<classpathcontainers>
			<classpathcontainer>org.eclipse.jst.server.core.container/org.eclipse.jst.server.tomcat.runtimeTarget/Apache Tomcat v6.0</classpathcontainer>
			<classpathcontainer>org.eclipse.jst.j2ee.internal.web.container
			</classpathcontainer>
			<classpathcontainer>org.eclipse.jst.j2ee.internal.module.container
			</classpathcontainer>
		</classpathcontainers>
		<additionalprojectfacets>
			<jst.web>2.5</jst.web>
		</additionalprojectfacets>
	</configuration>
</plugin>

Specify J2EE module dependencies

The dependent projects need to specify the library projects as J2EE module dependencies.

Right click on the project -> properties -> J2EE Module dependency. Just click on the projects the current project depends on.

Build Time

Unless necessary don’t specify the groupId and version in a sub-module unless specifically needed. As per Maven if those tags are not specified then the parent’s tags are read. In most cases this is the desired behavior.

Dependencies between projects

Say you have a parent project with 2 sub projects.

• test-parent
  • test-common
  • test-web-project

Say test-web-project depends on test-common you can specify the following in the test-web-project.

    <dependency>
      <groupId>com.test</groupId>
      <artifactId>test-common</artifactId>
      <version>${version}</version>
    </dependency>

When the project is built the system will include the dependency in the WAR files WEB-INF/lib directory. You would not need to worry about changing the version of the dependency for each sub-module since the ${version} expression will grab from the parent’s version number.

Jetty implementation broken?

At the time of this writing it seems like Jetty does not behave as expected. I am expecting the changes I make to test-common be visible when I restart jetty. At this moment the only time jetty picks up the changes is when I “mvn install” on the parent. Why jetty does not have a concept of “J2EE module dependencies” like eclipse is beyond me.

Are you faced to a 401 status code when invoking mvn site:deploy?

Like this one?
Embedded error: Failed to transfer file: http://server:port/dir/projectname//./changes-report.html. Return code is: 401


Then

1. check your pom.xml if the site-id in the distribution-section of the pom.xml matches any server-id setting in your settings.xml.
2. check if the password is still valid!

For example the following pom.xml and settings.xml DO NOT match. Note the difference between BARNAME and FOONAME! This cannot work.

pom.xml:

   <distributionManagement>
     <site>
       <!-- does not match FOONAME -->
       <id>BARNAME</id>
       <url>${site-base-url}/projectname/</url>
     </site>
   </distributionManagement>

.m2/settings.xml:

<?xml version="1.0" encoding="UTF-8"?>
<settings 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/settings-1.0.0.xsd">
  <servers>
    <server>
       <!-- does not match BARNAME -->
      <id>FOONAME</id>
      <username>XXXXXX</username>
      <password>XXXXXX</password>
    </server>
  </servers>
</settings>

To setup a proxy to be used by Maven only, you need to have it defined in the settings.xml file.
This file is located in [USR_HOME]\.m2 directory (C:\Documents and Settings\[USERNAME]\.m2 for Windows users).
Here’s an example of the file:


<settings>
  <proxies>
   <proxy>
      <active>true</active>
      <protocol>http</protocol>
      <host>[PROXY SERVER]</host>
      <port>[PROXY PORT]</port>
      <username>[PROXY USERNAME]</username>
      <password>[PROXY PASSWORD]</password>
      <nonProxyHosts>www.website1.com|*.website2.com</nonProxyHosts>
    </proxy>
  </proxies>
</settings>


To setup a proxy to be used for a Java application:


System.getProperties().put("http.proxyHost", [PROXY SERVER]);
System.getProperties().put("http.proxyPort", [PROXY PORT]);
System.getProperties().put("http.proxyUser", [PROXY USERNAME]);
System.getProperties().put("http.proxyPassword", [PROXY PASSWORD]);


To display the proxy server used for a particular URL:

URL url = new URL("http://www.treasurydirect.gov/xml/CPI_20090814.xml");
System.out.println(ProxySelector.getDefault().select(url.toURI()));


Yep, i’ve build my own archetype and everytime i’ve created a new maven project with this archetype the java nature has been missing. So i’ve searched for more then 8 hours for a solution and finally found a small page of a developer who had the same problem. The solution is so easy … just delete the .metadata directory of you Eclipse Workspace and every Maven Project with your archetype will have the java nature in that Workspace out of the box.

Hope this helps some people

This page describes the process of integrating the Spring framework with JSF. We will take an application that already has JSF and Spring components fully initialized and ready to go. We will prove this by displaying 2 links that allow those 2 frameworks to draw a page.

The integration will consist of having the user submit a JSF page. The JSF framework will handle the page submit and pass the information on to a spring enabled beans.

Spring MVC is not absolutely required to get this to work. You could have only used the core spring (DI) container but for the purposes of this page we will have it hang around.

Requirements

• Maven2
• Basic understanding of IOC and The Spring
• Basic understanding of JSF

Having JSF Managed Beans Delegate to Spring Managed Beans

We will be using the popular “DelegatingVariableResolver” to integrate these two frameworks together. The DelegatingVariableResolver class provides the ability for Spring managed beans to be injected into JSF manged beans. This is a powerful technique to allow business logic that is managed in the spring container  available for JSF applications to use.

Creating the Project

We will create this project using an archetype and walk thru the different parts that make this all work.

generate

mvn archetype:generate -DarchetypeGroupId=org.vtechfw -DarchetypeArtifactId=springmvc-jsf-archetype -DarchetypeVersion=1.0-SNAPSHOT -DarchetypeRepository=http://www.vermatech.com/m2repo

Maven will prompt you for some information. It is best to answer like the following.

groupId: testpackage
artifactId: springJSF

Hit enter for defaults for the rest of the questions.

Run

cd to the project’s directory. (cd springJSF)

mvn jetty:run

View the project

Navigate to the following page: http://localhost:8080/

1. The spring mvc configuration is read applicationContext.xml and spring-servlet.xml
2. The faces configuration file is read faces-config.xml

The system completes the initialization and the web application is ready to serve requests at http://localhost:8080

The application displays a welcome page with 2 links. One points to the Faces JSP file that displays a text box that allows the user to enter values and submit. The second link displays a welcome page that is rendered by the SpringMVC framework.

How to get JSF to use Spring Beans Works

Enable the JSF system to use DelegatingVariableResolver.

Add the following in the faces-config.xml

<application>
   <variable-resolver>org.springframework.web.jsf.DelegatingVariableResolver</variable-resolver>
</application>

Create a Spring Managed Bean

Actually you dont need to create one if you already generated the project. For documentation purposes the bean is listed here.

package testpackage.quickstart.springmvc;

import java.text.DateFormat;
import java.text.SimpleDateFormat;
import java.util.Date;

import org.springframework.stereotype.Service;

@Service("datePrintModel")
public class DatePrintModelImpl implements DatePrintModel {
	private DateFormat dateFormat = new SimpleDateFormat("EEE, d MMM yyyy HH:mm:ss Z");

	public String getDateAsString() {
		System.out.println("getDataAsString called.");
		return dateFormat.format(new Date());
	}
}

Setup the JSF Managed Bean

Add the DatePrintModel and its setters and getters to the managed been below.

After the change it should look something like this.

package testpackage.jsftest;

import javax.faces.event.ValueChangeEvent;

import testpackage.quickstart.springmvc.DatePrintModel;

public class MessageModel {

	private DatePrintModel datePrintModel;

	public DatePrintModel getDatePrintModel() {
		return datePrintModel;
	}

	public void setDatePrintModel(DatePrintModel datePrintModel) {
		this.datePrintModel = datePrintModel;
	}

	public void printMessage(ValueChangeEvent e) {
		System.out.println("old value was: " + e.getOldValue());
		System.out.println("new value is: " + e.getNewValue());
	}

	public void callSpringModel() {
		System.out.println("calling the spring model...");
		datePrintModel.getDateAsString();
	}
}

Modify the faces-config.xml to look like this…

<?xml version='1.0' encoding='UTF-8'?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"
              version="1.2">

<managed-bean>
	<managed-bean-name>message</managed-bean-name>
	<managed-bean-class>java.lang.String</managed-bean-class>
	<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
<managed-bean>
	<managed-bean-name>messageModel</managed-bean-name>
	<managed-bean-class>testpackage.jsftest.MessageModel</managed-bean-class>
	<managed-bean-scope>session</managed-bean-scope>
	<managed-property>
		<property-name>datePrintModel</property-name>
		<value>#{datePrintModel}</value>
	</managed-property>
</managed-bean>
</faces-config>

As you can see above the managed-bean property has been added.

Modify the JSP

helloWorld.jsp

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %>

<f:view>
    <html>
    <head>
        <title>Hello World JSF Example</title>
    </head>
    <body>
    <h:form>
		<p>This is a simple hello world page using Faces.</p>
		<p>Enter your message here: <br/>
		<h:inputText valueChangeListener="#{messageModel.printMessage}" value="#{message}" size="35"/></p>
		<h:commandButton value="Submit" action="#{messageModel.callSpringModel}"/>
    </h:form>
    <p>after submit check server console for output.</p>
    </body>
    </html>
</f:view>

Run and view The Project

mvn jetty:run

http://localhost:8080

That’s all for now!

In real world applications we have all too often external dependencies in test cases. Sometimes theses third party are not always available (i.e. remote webservices).

For continuous integration I want check a minimal set of tests but for my local development i want check a maximal set of tests. I want run my tests on command line (via maven) and in eclipse (via testng-plugin).

Here is my idea to do that …

My project super pom defines 2 profiles:

• test-min
  1. active by default
  2. exclude testng groups (online-tests, thirdparty-tests,…)
• test-max
  1. run a defined testng suite
  2. the suite defines a maximal set of test (all testng groups)

<profiles>
  <profile>
    <id>test-min</id>
    <activation>
      <activeByDefault>true</activeByDefault>
    </activation>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <inherited>true</inherited>
          <configuration>
            <excludedGroups>${excludedTestGroups}</excludedGroups>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
  <profile>
    <id>test-max</id>
    <build>
      <plugins>
        <plugin>
          <artifactId>maven-surefire-plugin</artifactId>
          <inherited>true</inherited>
          <configuration>
            <suiteXmlFiles>
              ${basedir}/src/test/resources/Testsuite.xml
            </suiteXmlFiles>
          </configuration>
        </plugin>
      </plugins>
    </build>
  </profile>
</profiles>
<properties>
  <excludedTestGroups>online,integration,thirdparty</excludedTestGroups>
</properties>

Each subproject must define a testng src/test/resources/Testsuite.xml:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="TestSuite for Foobar">
  <test name="Online Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="online" />
      </run>
    </groups>
  </test>
  <test name="Integration Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="integration" />
      </run>
    </groups>
  </test>
  <test name="Thirdparty Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <include name="thirdparty" />
      </run>
    </groups>
  </test>
  <!-- Each project can define MORE groups: i.e. "interactive" -->
  <test name="Other Tests">
    <packages>
      <package name="de.foobar.*" />
    </packages>
    <groups>
      <run>
        <exclude name="online" />
        <exclude name="integration" />
        <exclude name="thirdparty" />
        <!-- Each project can define MORE groups: i.e. "interactive" -->
      </run>
    </groups>
  </test>
</suite>

If the sub project defines more exclude groups (i.e. a additional “interactive” group) then the pom must overwrite the excludedTestGroups property:

<properties>
  <excludedTestGroups>online,integration,thirdparty,interactive</excludedTestGroups>
</properties>

To check the correct configuration of the two profiles we can use help:effective-pom:

mvn -Ptest-min help:effective-pom | less

<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <excludedGroups>online,integration,thirdparty,interactive</excludedGroups>
  </configuration>
</plugin>

mvn -Ptest-max help:effective-pom | less

<plugin>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <suiteXmlFiles>
      <suiteXmlFile>d:\foobar\src/test/resources/Testsuite.xml</suiteXmlFile>
    </suiteXmlFiles>
  </configuration>
</plugin>

Now I can run min/max tests for each project which depend on the above super-pom. The test-min is the default profile and would be used on the continuous integration system (i.e. TeamCity).

Try it

This page will describe the process of creating a JSF application and running it within 10 minutes.

Requirements

• Maven 2

Generate the web application

First we start with a maven archetype

mvn archetype:generate

Choose option 18 which is a (maven-archetype-webapp)

For the group id enter: test

For the artifactId enter: jsfTestWeb

cd to the project directory and modify the pom.xml file. It should look like this…

<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/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>test</groupId>
	<artifactId>jsfTestWeb</artifactId>
	<packaging>war</packaging>
	<version>1.0-SNAPSHOT</version>
	<name>jsfTestWeb Maven Webapp</name>
	<url>http://maven.apache.org</url>
	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>3.8.1</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>javax.faces</groupId>
			<artifactId>jsf-api</artifactId>
			<version>1.2_02</version>
		</dependency>
		<dependency>
			<groupId>javax.faces</groupId>
			<artifactId>jsf-impl</artifactId>
			<version>1.2-b19</version>
		</dependency>
		<dependency>
			<groupId>javax.servlet</groupId>
			<artifactId>jstl</artifactId>
			<version>1.1.2</version>
		</dependency>
		<dependency>
			<groupId>taglibs</groupId>
			<artifactId>standard</artifactId>
			<version>1.1.2</version>
		</dependency>
	</dependencies>
	<build>
		<finalName>jsfTestWeb</finalName>
		<plugins>
			<plugin>
				<groupId>org.mortbay.jetty</groupId>
				<artifactId>jetty-maven-plugin</artifactId>
			</plugin>
		</plugins>
	</build>
</project>

Modify the WEB-INF/web.xml

<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app>
  <display-name>Archetype Created Web Application</display-name>

  <servlet>
  	<servlet-name>Faces Servlet</servlet-name>
  	<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
  	<load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
  	<servlet-name>Faces Servlet</servlet-name>
  	<url-pattern>*.faces</url-pattern>
  </servlet-mapping>

  <welcome-file-list>
  	<welcome-file>index.jsp</welcome-file>
  </welcome-file-list>

</web-app>

Create a WEB-INF/faces-config.xml

<?xml version='1.0' encoding='UTF-8'?>
<faces-config xmlns="http://java.sun.com/xml/ns/javaee"
              xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
              xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd"
              version="1.2">

<managed-bean>
	<managed-bean-name>message</managed-bean-name>
	<managed-bean-class>java.lang.String</managed-bean-class>
	<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
<managed-bean>
	<managed-bean-name>messageModel</managed-bean-name>
	<managed-bean-class>test.MessageModel</managed-bean-class>
	<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
</faces-config>

Create a jsp helloWorld.jsp

<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<%@ page contentType="text/html;charset=UTF-8" language="java" %>
<%@ taglib prefix="f" uri="http://java.sun.com/jsf/core" %>
<%@ taglib prefix="h" uri="http://java.sun.com/jsf/html" %>

<f:view>
    <html>
    <head>
        <title>Hello World JSF Example</title>
    </head>
    <body>
    <h:form>
		<p>This is a simple hello world page using Faces.</p>
		<p>Enter your message here: <br/>
		<h:inputText valueChangeListener="#{messageModel.printMessage}" value="#{message}" size="35"/></p>
		<h:commandButton value="Submit" action="submit"/>
    </h:form>
    </body>
    </html>
</f:view>

Create a managed Bean

src/main/java/test.MessageModel.java

package test;

import javax.faces.event.ValueChangeEvent;

public class MessageModel {
	public void printMessage(ValueChangeEvent e) {
		System.out.println("old value was: " + e.getOldValue());
		System.out.println("new value is: " + e.getNewValue());
	}
}

Run the JSF application

Save all files and run the application in jetty.

mvn jetty:run

The application should come up when you point your browser to http://localhost:8080

Type in some text and you should see some output on the console window.

Right click on the page and click view source. You will notice JSF generated code.

That’s all for Now!

This position is an Application Administrator to support operations within our client’s department. This position has a critical role in delivering our services to clients and ensuring successful ongoing operation of our applications and services. It services a highly interactive software development build/release process as well as a rich operational environment with many interrelated applications/database services. The candidate should be self-motivated, detail oriented, adaptable to change and must work well in a flexible team environment with developers, QA, operations staff, system administrators and managers.

RESPONSIBILITIES:

Application and database support

• Provide on-going database administration in both back-end and front-end with application infrastructure support for our client’s administration systems, including the deployment of new applications.
• Review the physical design of existing databases for optimal database structures, database performance tuning, security, database backup/recovery strategy, implementing high-availability, and pro-active and reactive performance analysis, monitoring, troubleshooting and resolution of issues, capacity planning, monitoring data growth and system utilization, trend analysis and predicting future database resource requirements.
• Install web-base applications from ground up to full-ballooned implementation and support, including configuration at Unix/Linux/Windows system level, back-end integration with database, front-end integration with user-interface, final delivery to users to fulfill users’ requirement and on-going maintenance.
• Take the lead in ensuring that application and web services are configured and tuned according to application needs; provide troubleshooting as needed.
• Work with System Administrators to ensure test and production boxes conform to the software application configuration needs.
• Support the department-wide infrastructure application for database management, system monitoring and notification, job scheduling, deployment, provision and patching automation, application topology and service level management for campus-wide system performance.

Build/release activities

• Manage the build, tagging and release processes for a number of interdependent Java web applications and background processes in the QA and production environments. Ensure the build and release process is scalable and repeatable.
• Work with the development team to ensure efficient and understandable build procedures are adhered to and conform to a standard process for configuration and release management
• Develop and maintain tools that automate the building of software releases for an Agile-based development process. This is one of continuous integration, where the automated build process can be run many times a day if necessary.
• Work with and support the QA team to ensure automated test suites run as part of the continuous integration build process.

REQUIREMENT FOR SKILL AND COMPETENCIES:

• Expert hands-on with shell scripts, other scripting languages, preferably Perl, and tool automations
• Minimum 2 years database administration experience in Oracle and 3 years Application administration experience in Unix/Linux infrastructure environments is required.
• Hands-on experience of Oracle databases 10g for 24/7 database operations and tool automation in installation, configuration, backup/recovery, startup/shutdown, data refresh, and application integrations.
• Experience with OEM/Grid Control is highly desired.
• Knowledge and understanding of large scale ERP implementation and support like Oracle Financial and PeopleSoft systems.
• Expert knowledge of Apache and Tomcat, and other web/application servers such as JBoss
• Strong Unix and system administration skills with basic network and security knowledge
• Strong experience and ability in web applications deployment, configuration and integration from both OpenSource and Commercial based systems with or without sophisticated vendor support.
• Java/J2EE based programs
• Java/servlet/JSP based web applications
• Experience with Subversion, PVCS or similar source code repository
• Experience with Maven and familiarity with automated build processes
• Experience with the Agile development methodology and concepts of extreme programming and continuous integration
• Understanding of the layers/tiers of web applications and the communication protocol between the tiers with networking protocols (TCP/IP, HTTP, SSL, DNS, FTP, etc.)
• Ability to multi-task and work in a team environment is critical and should have excellent communication skills in both verbal and written forms.
• Ability to manage multiple competing priorities and work under pressure in high stress situations
• Excellent communication skills in both verbal and written
• Ability to work under pressure and to deliver results in a complex and dynamic operational environment

Qualifications

Minimum 5 years as an IT professional in build/release and application/database administration, plus one or more of the following areas: IT infrastructure operations 24/7, systems analysis and design, or application development.

Education
Bachelors Degree in Computer Science, Engineering or related field or equivalent experience

If you are interested, please send your resume to tsotelo@mindsource.com.

Today i  had to do some merging of artifacts (code and pom.xml). Then i wondered, why the tests didn’t run properly.

“java.lang.OutOfMemoryError: Java heap space” was the reason. But why? I didn’t change the tests and i carefully merged the configuration. So i connected VisualVM to the surefire process and saw that only ca. 67MB max heap were available. I reviewed my MAVEN_OPTS, but my settings didn’t apply…

The culprit is a bug. See http://jira.codehaus.org/browse/SUREFIRE-501.

The workaround is to place your max heap configuration in the configuration section of the plugin. As seen in the linked bug issue:

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-surefire-plugin</artifactId>
  <configuration>
    <!-- http://jira.codehaus.org/browse/SUREFIRE-501 -->
    <argLine>-Xmx256m</argLine>
  </configuration>
</plugin>

mvn archetype:create -DgroupId=com.mycompany.app -DartifactId=my-webapp -DarchetypeArtifactId=maven-archetype-webapp

This is a good guide to create multi-mode maven projects in Eclipse:

http://maven.apache.org/plugins/maven-eclipse-plugin/reactor.html

Also useful to refactor existing project to put several modules bellow a parent module that wasn’t created when it should.

Read all about a tale of planetary woe; SumbandilaSat payload activation going well;  astronomy stars and a giant ribbon discovered at the edge of the solar system… (more)

This page will show you how to create an Jave Enterprise application using Maven’s multi-module and archetype capabilities.

Requirements

• Maven
• Eclipse IDE
• Java 5 or above
• Access to the Command Prompt

Hello Enterprise

In the example we will name the application HelloEnterprise. This will be the parent project. The project will have 3 sub-projects listed below.

1. HelloModel – contains the business logic
2. HelloWeb – contains the Web application flow control logic
3. HelloEar – small sub-project used simply to create the ear

Create the Parent Project

The first step we will do is to create the parent project. This project will contain the others. Name the project something that is generic to the problem at hand.

mvn archetype:generate

choose the default (15) “maven-archetype-quickstart”

Define value for groupId: : test
Define value for artifactId: : hello-enterprise
Define value for version:  1.0-SNAPSHOT: :
Define value for package:  test: :
Confirm properties configuration:
groupId: test
artifactId: hello-enterprise
version: 1.0-SNAPSHOT
package: test
 Y: :

cd hello-enterprise
Edit the pom.xml and change the packaging to say pom instead of jar.

Create the Model project

For this step we will create a very simple model project that simply contains a single Model class. Though this is a very simple project it does show you how you can combine sub-modules into one ear file in the end.

mvn archetype:generate

Again choose option 15 just like before. This time answer the artifact id should be “hello-enterprise-model”.

Go ahead and create the model class

cd hello-enterprise-model

mvn eclipse:eclipse

Import the project into eclipse and create the following class and interface

Bean

package test;

import java.math.BigDecimal;

public class Product {
	private Integer id;
	private String name;
	private BigDecimal price;

	public Product(Integer id, String name, BigDecimal price) {
		this.id = id;
		this.name = name;
		this.price = price;
	}

	public Integer getId() {
		return id;
	}
	public void setId(Integer id) {
		this.id = id;
	}
	public String getName() {
		return name;
	}
	public void setName(String name) {
		this.name = name;
	}
	public BigDecimal getPrice() {
		return price;
	}
	public void setPrice(BigDecimal price) {
		this.price = price;
	}
}

Interface

package test;

import java.util.List;

public interface ProductDataManager {

	public abstract List<Product> getAllProducts();

}

Class

package test;

import java.math.BigDecimal;
import java.util.ArrayList;
import java.util.List;

public class ProductDataManagerImpl implements ProductDataManager {
	/* (non-Javadoc)
	 * @see test.ProductDataManager#getAllProducts()
	 */
	public List<Product> getAllProducts() {
		List<Product> list = new ArrayList<Product>();

		list.add(createProduct(1, "test1", BigDecimal.valueOf(12)));
		list.add(createProduct(2, "test2", BigDecimal.valueOf(13)));
		list.add(createProduct(3, "test3", BigDecimal.valueOf(14)));

		return list;
	}
	private Product createProduct(Integer id, String name, BigDecimal price) {
		Product product = new Product(id, name, price);
		return product;
	}
}

cd ..

Create the web project

To create the web project we will use an existing archetype that was created my me. It is an archetype of a very simple spring MVC application that prints some static text on the screen.

mvn archetype:generate -DarchetypeGroupId=com.vermatech \
-DarchetypeArtifactId=springmvc-archetype -DarchetypeVersion=1.0-SNAPSHOT \
-DarchetypeRepository=http://www.vermatech.com/m2repo

Answer the questions like this:

Define value for groupId: : test
Define value for artifactId: : hello-enterprise-web
Define value for version:  1.0-SNAPSHOT: :
Define value for package:  test: :
Confirm properties configuration:
groupId: test
artifactId: hello-enterprise-web
version: 1.0-SNAPSHOT
package: test
 Y: :

You may test the project you just created from an archetype by typing mvn jetty:run from the hello-enterprise-web folder. Point your browser to: http://localhost:8080/ and verify everything is ok.

When you are done return to the command prompt and cd to the hello-enterprise directory again.

Create the Ear Project

Finally we will create an EAR project that will allow us to create an EAR file.

mvn archetype:generate

choose option 15 (default)

Edit pom.xml and make sure it looks like the following.

hello-enterprise/hello-enterprise-ear/pom.xml

<?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>
  <parent>
    <artifactId>hello-enterprise</artifactId>
    <groupId>test</groupId>
    <version>1.0-SNAPSHOT</version>
  </parent>
  <groupId>test</groupId>
  <artifactId>hello-enterprise-ear</artifactId>
  <packaging>ear</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>hello-enterprise-ear</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>test</groupId>
      <artifactId>hello-enterprise-model</artifactId>
      <version>1.0-SNAPSHOT</version>
    </dependency>
    <dependency>
      <groupId>test</groupId>
      <artifactId>hello-enterprise-web</artifactId>
      <version>1.0-SNAPSHOT</version>
      <type>war</type>
    </dependency>

  </dependencies>
  <build>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-ear-plugin</artifactId>
        <version>2.3.2</version>
        <!-- configuring the ear plugin -->
        <configuration>
          <modules>
            <webModule>
              <groupId>test</groupId>
              <artifactId>hello-enterprise-web</artifactId>
            </webModule>
          </modules>
        </configuration>
      </plugin>
    </plugins>
  </build>
</project>

Save and exit. Return to the hello-enterprise (parent) directory and run the following command:

Start the build process

mvn package

You will see a bunch of stuff happen and at the end you will see the following results.

[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] ------------------------------------------------------------------------
[INFO] hello-enterprise ...................................... SUCCESS [1.194s]
[INFO] hello-enterprise-model ................................ SUCCESS [0.938s]
[INFO] springmvc-quickstart Maven Webapp ..................... SUCCESS [1.078s]
[INFO] hello-enterprise-ear .................................. SUCCESS [0.647s]
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

At this time you can open the ear project’s target folder and you will see the newly created ear.

Deploy The Ear file

Deploy the Ear to your Application server and do an application checkout.

That’s All

The following page describes the process of creating a simple spring MVC application using an archetype. The archetype was created my me for testing purposes. All it does is print a simple message to the browser when you navigate to the application.

Requirements

Maven

Access to the command prompt

The Maven page above talks about eclipse you don’t need eclipse to install and run the simple springMVC application described here.

Creating the Project

Execute the following archetype to create the spring MVC application

mvn archetype:generate -DarchetypeGroupId=com.vermatech \
-DarchetypeArtifactId=springmvc-archetype -DarchetypeVersion=1.0-SNAPSHOT \
-DarchetypeRepository=http://www.vermatech.com/m2repo

Answer some simple questions:

Define value for groupId: : com.test2
Define value for artifactId: : vtSpringTest
Define value for version:  1.0-SNAPSHOT: :
Define value for package:  com.test2: :
Confirm properties configuration:
groupId: com.test2
artifactId: vtSpringTest
version: 1.0-SNAPSHOT
package: com.test2
 Y: :

Running the Application in Jetty

Execute the following in the project’s folder.

mvn jetty:run

Navigate to the following url http://localhost:8080/ and you should see a Welcome page come up.

Thats All!

Well, I use maven to organize and automatically download project dependencies, basically open source libraries.

With maven you can get a dependency graph like this one(actually generated by eclipse maven plugin):

where your project is the top one.
The best way to grasp easily what maven is, from my point of view is:

To read:

http://maven.apache.org/what-is-maven.html

Download maven:

http://maven.apache.org/download.html

Uncompress it somewhere in the hard disk, create the enviroment variable home M2_HOME to the uncompressed folder.
It is okay to place M2_HOME/bin in the path to use the maven executable (mvn.bat or mvn.sh)

Then integrate it with eclipse or netbeans to actually see how the IDE’s download automatically all project dependencies:

For eclipse galileo, for example:

Install the maven eclipse plugin, from here:

http://m2eclipse.sonatype.org/

(there is an update site for eclipse)

Then add this:

-vm
/usr/java/your_jdk_folder/bin/java

to eclipse.ini for some reason I don’t understand

THen go to: Window > Preferences > Maven > Installations in eclipse and add your recently donwloaded and uncompressed maven installation, select it.

Then you can File > Import > Maven Project and point it to this sample project (with some example dependencies):

http://www.2shared.com/file/9360954/c26ff629/admision.html (download and extract)

Then, you’ll see how eclipse(maven in the background) automatically download the project dependencies under the “Maven dependencies” category that you can check directly in the pom.xml (the file that actually defines a maven project).

For a general view about the maven repositories, this is how a maven repository looks:

http://hl7api.sourceforge.net/m2/

And you can check your own maven local repository at> $home/.m2/repository, in windows c:/Documents and Settings/User/.m2/repository.

Well, I have just a few months with maven, and I’m realizing it is more than a management/build manager, it is fully extensible with your own plugins, allowing you to do almost anything with/from your project sources.

Furthermore, migrating an eclipse/netbeans/etc native project to maven is not too hard, it is usually no more than create a pom.xml file, place there your own project dependencies and move your sources to /maven_project/src/main/java, the resources (log4j.properties, etc) to /maven_project/src/main/resources and unit tests to /maven_project/src/test/java.

I’ve had the chance over a recent weekend to have a first crack at a web framework called Vaadin.

I was originally browsing for news about the latest release of Google’s GWT framework when I stumbled on a reference to Vaadin, and decided to go take a look. What I found intrigued me, and I decided to take it for a test drive, as I was down sick for a couple of days with a laptop nearby…. My back became annoyed with me, but it was worth it, I think.

First Look
First off, the practicalities: Vaadin is open source, and with a reasonable license, the Apache License. The essential bits of Vaadin are contained in a single JAR, and it’s both Ant and Maven friendly right out of the box.

The next thing that struck me about Vaadin was the documentation. The first unusual thing about it’s documentation was the fact of it’s existence, as open source projects are downright notorious for poor documentation. Vaadin is a pleasant exception, with tons of examples, a well-organized API doc, in the usual JavaDoc format, and even the “Book of Vaadin”, an entire PDF book (also available in hardcopy) that takes you through Vaadin in enough detail to be immediately productive.

Given that surprisingly pleasant start, I dug deeper, creating a little app of my own.

Just the Java, Ma’am
The main thing that kept me interested in Vaadin once I started digging further was that it’s pure Java. Many frameworks talk about writing your UI work in Java, such as Wicket, but there’s still a corresponding template and some wiring that happens to put the code and the template together. Not so with Vaadin.

When they say “just Java”, they mean it – your entire UI layer is coded in Java, plain and simple. No templates, no tag libraries, no Javascript, no ‘nuthin. It’s reminiscent of the Echo framework, except in Vaadin’s case the Javascript library that your code automatically produces is Google’s GWT, instead of Echo’s own Core.JS library.

Unlike GWT, though, the Vaadin approach doesn’t bind you to any specific source code though, it’s just a binary jar you put on your classpath.

The only thing in my sample app, other than 2 Java files, was a web.xml and a css stylesheet, both of which were only a few lines long. And this was no “Hello, World”, either, but a rich AJAX webapp with a tree menu, fancy non-modal “fading” notifications, images, complex layouts, and a form with build-in validation. And it took maybe 4 hours of total work to produce – and that was from a standing start, as I’d never heard of Vaadin before last Thursday. Not bad, not bad at all.

I found I was able to get a very capable little webapp up and running with no need to invent my own components, even though I had trees and sliders and menus and other assorted goodies on the page. It worked in every browser I was able to try it in, which is certainly not the case for my own hand-rolled JavaScript most of the time

I haven’t yet tried creating my own custom components, but it certainly looks straightforward enough.

I did try linking to external resources, and included non-Vaadin pages in my app, with no difficulties, so it appears that Vaadin plays well with others, and can be introduced into an existing project that uses, for instance, a whack of JSP’s that one might want to obsolete.

Webapps
I think Vaadin warrants more exploration, and I intend to put it further through its paces in the next few weeks. It appears extremely well-suited to web applications, as opposed to websites with a tiny bit of dynamic stuff in them.

It offers an interesting alternative to some of the patterns I’ve seen for advanced dynamic webapp development so far.

One approach I’ve seen a lot is to divide the duties of creating an app into the “back end” services and the “UI”. Generally the UI is written in either JavaScript, or uses Flex or some other semi-proprietary approach. The “back end” stuff is frequently written to expose it’s services as REST, then the two are bolted together. The pain point here happens when the two meet, as it’s common and easy to have minor (or major!) misunderstandings between the two teams. This usually results in a lot of to-and-fro to work out the differences before the app comes all the way to life.

The other approach, more common on smaller or resource-strapped teams, is to have the same group responsible for both UI and back-end services. This reduces the thrash in the joints a bit, but doesn’t eliminate it, because the two technologies on the two sides of the app aren’t the same. You can’t test JavaScript the same way you write Java, for instance, and they’re two different languages – one of which (Java) has far better tooling support than the other. IDE support, for instance, is superb for Java, and spotty at best for JavaScript.

With Vaadin, both of these approaches become unnecessary, as its the same technology all the way through (at least, what you write is – technically it’s still using JavaScript, but because that’s generated, I don’t count it).

You get to use all of the tools you know and love for the back-end services to write the code for the UI, which you can then unit and functional test to your heart’s content.

The temptation to mix concerns between UI code and back-end service code must still be resisted, of course, but at least that code isn’t buried somewhere in the middle of a JSP page, ready to leap out and bite you later.

Because you’re using dynamic layouts, the app always fits properly on the screen without any extra work, addressing a pet peeve of mine, the “skinny” webapp, restraining itself to the least common denominator of screen size, thus rendering impotent my nice wide monitors.

Scala
Just because Vaadin is a Java library doesn’t restrict you to using Java to drive it, however. I made another little webapp where the whole UI was defined in Scala, calling the Vaadin APIs, and it worked like a charm. In some ways, Scala is an even better fit for Vaadin than straight Java, I suspect. I haven’t tried any other JVM compatible language, but I see no reason they wouldn’t work equally well.

Deployment and Development Cycle
As I was building the app with Maven, I added a couple of lines to my POM and was able to say “mvn jetty:run” to get my Vaadin app up and running on my local box in a few seconds. My development cycle was only a few seconds between compile and interactive tests, as I was experimenting with the trial-and-error method.

TDD would be not only possible, but easy in this situation.

I successfully deployed my little Vaadin app to ServiceMix, my OSGi container of choice, without a hitch.

Performance appeared excellent overall, although I haven’t formally tested it with a load-testing tool (yet).

Summary
So far, I’m impressed with Vaadin. I’m more impressed with any web framework I’ve worked with in a number of years, in fact. I’m sure there are some warts in there somewhere, but for the benefits it brings to the table, I suspect they’re easily worth it. I think the advantages to teams that already speak fluent Java is hard to overstate, and the productivity to produce good-looking and functioning webapps is quite remarkable.

Over the next few weeks I’ll push it a bit harder with a complex example application, and see how it stacks up against other web app technologies I’ve worked with in a more realistic scenario.

By: Mike Nash

Two weeks ago I attended to the event The Developer’s Conference, down here in São Paulo, Brazil. I covered it here and here. One topic I decided to cover separated is Spring Roo. Rod Johnson, from SpringSource presented it in the conference, and really got my attention.

During the last few days I’ve being spending a few minutes per day with the tool. Following are an explanation about what it does, and my impressions in general. Hope you enjoy =)

The statement that describes better what Roo tries to do is “Roo is Rails for Java, but better”. Rod Johnson said something similar to this during his presentation in the TDC event, and I can agree with that. Rails productivity is nice, sure, but it doesn’t have the power of the Java platform. So bringing this productivity “home”, to Java, is an excelent idea.

To achieve this goal, Roo generates code for you. This isn’t, of course, a new idea. But the way Roo does it is what makes it really interesting. The concept is that you should be able to read and edit any code generated by the tool. Also, you should be able to use whatever IDE you prefer during development, without Roo getting in your way – I actually use Netbeans to edit the source code files, and although the IDE they officially support is Eclipse (the base for their Spring Tool Suite), it worked just fine.

The code generated by Roo has also desirable qualities: it follows good programming practices, like separation of concerns, and has good performance – there is no reflection in any of its “magic” to slow things down, for example.

This is how Roo looks like when running:

Roo Shell

This is the Roo shell. It is where you type commands and execute tasks when using the tool. It features TAB completion, which works very nicely, and a lot of development support – you can type hint anytime to get a help message. Also, you can type help to see full list of commands currently available.

We haven’t created a project yet, so hint shows this:

Hint on an Empty Folder

Lets take a look at Roo in action. In the next screenshot, I’m using the command project to create a new project called JCranky:

Project Creation

Notice the TAB completion working; also, notice how Roo tells you what it did to your files, so that you can keep an eye on his behavior

I’m don’t intend to write a tutorial, so I’ll just show one more code generation example and go back to commenting. Lets install persistence support, and then create an entity. The command to do the former is persistence setup and for the later is entity EntityName. The next two screenshots ilustrates the result of these commands:

Persistence Setup

Entity Creation

Again, notice how TAB completion helps us. We don’t have to remember all those commands. Just hit TAB and Roo tells you what commands are available. Notice on the entity creation that Roo created a few .aj files. This is one of its secrets: it uses Aspects to insert code into your class, making it more simpler during source editing time. So boilerplate code like getters, setters and toString are inserted automatically in your entities to you. To understand a little bit more about this, take a look at the Aspect J site.

I’m not a fan of Spring, which obviously is used a lot in Roo and in the generated sources. But this tool seems to work so nicely that it might make me change my mind. And the same thing goes for maven, which Roo uses in the generated sources. But in this case, Roo also allows you to replace maven if you want to – but in this case you will have to write your own plugin to do that, at least for now.

I’ll stop here, but if anyone asks for more I might feel like writing another post =D. But before closing, lets mention the only one thing I really hated about Roo: it seems to generate code with TABs instead of whitespaces. So, Roo developers, I beg you: please generate whitespaces! I know it is a small thing, but it really freaks me out…

For more information, besides the official site, these three blog posts are very interesting: Jump into Roo for extreme Java Productivity; Getting Started with Spring Roo and Exploring Roo’s Architecture.

bye!

EDIT: After Ben Alex’s comment I looked again into the sources generated for my tests and couldn’t find any TABs. So please ignore this part of the post, until I find them again =D

If you’re involved in a large software development effort in Java, then OSGi seems like a natural fit to keep things modular and thus maintainable. But every advantage can also be seen as a disadvantage: using OSGi you will end up with lots of small projects. Handling these and their interrelationships can be challenging.

Enter Maven. This build tool makes it a lot easier to build all these little (or not so little) projects. Which is a necessity, since a command line driven build tool is essential for doing Continuous Integration. And we all practice that, right?

However, as a developer it’s a pain to keep switching between your favorite IDE and the command line. Not to worry, Eclipse has plug-ins that handle just about any situation. Using M2Eclipse, you can maintain your POM from within the IDE.

But an Eclipse Maven project is not an Eclipse OSGi project. For handling OSGi bundles, one would want to use the Eclipse Plug-in Development Environment (PDE) with all the goodies that brings to OSGi development. There is, however, a way to get the best of both worlds, although it still isn’t perfect, as we will see shortly.

The trick is to start with a PDE project:

Make sure to follow the Maven convention for sources and classes and to use plain OSGi (so you’re not tied to Eclipse/Equinox):

Once you’ve created the project, you can add Maven support:

Make sure to use the same identification for Maven as for PDE:

Now you have an Eclipse project that plays nice with both PDE (and thus OSGi) and Maven. The only downside to this solution is that some information, like the bundle ID, is duplicated.

Segue abaixo as urls de alguns plugins que costumo instalar no eclipse:

http://download.jboss.org/jbosstools/updates/development/
http://m2eclipse.sonatype.org/update/
http://subclipse.tigris.org/update_1.6.x

For too long, developers have worked on disorganized application projects, where every part seemed to have its own build system, and no common repository existed for information about the state of the project. Now there’s help. The long-awaited official documentation to Maven is here.

หลังจากพยายามที่จะสร้าง Project ด้วย Maven ดูก็พบว่า มัน fail ขึ้น error Invalid target release : 1.6

เราก็เลยไปเปลี่ยน Path ให้ชี้ไปที่ JAVA6_HOME/bin แล้วก็ลอง run ดูใหม้่แต่ก็ยังติดปัญหาเดิมอยู่\

[INFO] ————————————————————————
[ERROR] BUILD FAILURE
[INFO] ————————————————————————
[INFO] Compilation failure
Failure executing javac, but could not parse the error:
javac: invalid target release: 1.6
Usage: javac

ทำไงดีหละ ……..

ลองหาดูใน Google จึงได้รู้ว่า Maven จะดูที JAVA_HOME ไม่ใช่ PATH หลังจากนั้นจึงเปลี่ยน JAVA_HOME ให้เป็น Version 6 ก็จะได้แล้วจ้า

We did talk about how to use Maven in Eclipse. So let’s move on to see how to integrate SVN and Maven in Eclipse.

For a simple Java project, only the /src folder and the pom.xml are needed to be stored in SVN repository. if you like to do development without the IDE. u can just check out the project to the file system of a computer with Maven installed and run the Maven commands in command prompt/terminal.

For Eclipse user, assume we have already import them in the SVN repository. How could we check out them in Eclipse such that developers can run the project immediately after check out?

Pre-requisites
—————————————-
1. Eclipse with subclipse and m2clipse installed
2. Maven installed

Check out the Maven Project in Eclipse
——————————————————————————–
1. An optional plugin Maven SCM handler for Subclipse is needed for Eclipse.

2. Open the SVN Repository View in Eclipse

3. Connected to your SVN repositoy

4. Selected the Maven Project and choose Check out as Maven Project…



















































5. After check out, you may need to configure the project build path to your desired JDK instead of the Eclipse default JRE.

6. mvn build/install the project once. Then open the Team Synchronizing perspective and add all those Eclipse related files such as .settings and the Maven created folders like /target to SVN ignore.

Done =)

For a long time the java classpath was something I only sort of understood. I think I’m finally getting a handle on it.

What is (or was) also confusing for me is how the classpath is managed with tomcat (or any other servlet container, but I’ve only used tomcat). When you look at the directories and files for a web application with tomcat you can probably figure it out; under WEB-INF are two directories, lib and classes. lib contains a bunch of jars, and classes containes your compiled java code.

You often hear that something needs to “be on the classpath.” The tomcat WEB-INF/classes directory is on the classpath. So if you have any configuration files that need to be on the classpath, you can put them in the classes directory. For example, your log4j configuration file log4j.xml, or, in my case, since I use logback, logback.xml goes in the classes directory. If you’re using spring, this is where you can put your applicationContext.xml file, and then in your web.xml you’d use

<listener>
    <listener-class>
        org.springframework.web.context.ContextLoaderListener
    </listener-class>
</listener>

<context-param>
    <param-name>
        contextConfigLocation
    </param-name>

    <param-value>
        classpath:spring/applicationContext.xml,
    </param-value>
</context-param>

I’ve created a subdirectory, spring, and put my spring configuration files in that.

When you use maven, it has this really convenient directory structure; first there is the src directory, and then in it is the directory main, then in main are two directories java and resources. In the java directory you put your java source code. The resources directory is where you put your configuration files. If you’re making a web application, when maven makes the war file it puts everything that was in the resources directory in the war’s WEB-INF/classes directory. Viola, your configuration files are “on the classpath.”

(I have a spring directory in the resources directory, src/main/resources/spring, and in it are all of my spring configuration files. That’s why there’s spring/ in front of the applicationContext.xml above.)

Here’s a diagram of a web application I’m working on, which is divided into several maven modules, and with arrows showing their dependencies.

The webapp module will be the controllers or action beans. It depends on the service module, which contains the business logic, which depends on the persistence module. Everyone depends on the api module; that’s where the interfaces are declared, and the service and persistence modules implement the interfaces. The model module is what I think of as the data transfer objects, or the domain objects; more or less dumb data POJOs with getters and setters. The classes in it are annotated with JDO persistence stuff.

So what’s the config module? Up above, when I was talking about tomcat and its classpath you may have noticed that I skipped over explaining its lib directory. Intuitively, all of the jars in the lib directory are on the classpath. But a better way of thinking about it is that the contents of the jars are on the classpath. Perhaps just then a lightbulb lit up over your head and you realized that you could put configuration files in a jar file and then put that jar file in the lib directory. Now we’re really talking viola! This next diagram is a tree listing of the config maven project.

|   pom.xml
|
+---src
|   +---main
|   |   \---resources
|   |       |   logback.xml
|   |       |
|   |       +---META-INF
|   |       |       jdoconfig.xml
|   |       |
|   |       \---spring
|   |               applicationContext.xml
|   |               jdo-gae-context.xml
|   |               jdo-hsql-context.xml
|   |               jdo-tx-context.xml
|   |
\---target
    |   waitlist-config-0.0.1-SNAPSHOT.jar
    |
    +---classes
    |   |   logback.xml
    |   |
    |   +---META-INF
    |   |       jdoconfig.xml
    |   |
    |   \---spring
    |           applicationContext.xml
    |           jdo-gae-context.xml
    |           jdo-hsql-context.xml
    |           jdo-tx-context.xml

Besides the pom.xml, the only thing it contains is the src/main/resources directory, where we put our configuration files. The target directory is created by maven when we do a build, compile, package, etc. And in it you can see that maven created a classes directory and copied everything from the resources directory into it. And here’s what the jar file looks like:

So now we have our configuration files neatly packaged, and our various maven modules can each depend on that, and no need to duplicate configuration files across your maven modules. In case you’re wondering why the light blue arrow is showing a dependency from the model module to the config module, that’s because sometimes I’ll add logging calls to the model and then it will need the logback.xml configuration file.