Part 2 - Enhancing the setup

As you can seen modularity has a price. Our application will be divided into multiple Maven projects / modules. Lets say in development I change 2-3 modules, then I need to build each one of them to test. This can be irritating and time wasting. Also I am a lazy developer, I will want to build them as one go. Hence I will now create a multi-module Maven build parent - child. I will just build the parent to build all my childs, including the aggregator ecrm project, which we will essentially deploy.

So we create a maven quick start archetype project. You can turn this into parent project as shown in Listing 1. Also I will refactor the pom in ercm project by moving dependencies and properties to the parent. Similarly view/pom.xml is modified to treat it as a child project.

Listing 1 - parent/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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <artifactId>ecrm</artifactId>
    <packaging>war</packaging>

    <name>ecrm</name>
    <url>http://maven.apache.org</url>

    <!-- ~~~~~~~~~~~~ -->
    <!-- DEPENDENCIES -->
    <!-- ~~~~~~~~~~~~ -->
    <dependencies>
        <dependency>
            <groupId>${project.groupId}</groupId>
            <artifactId>view</artifactId>
            <version>${project.version}</version>
        </dependency>
    </dependencies>

    <build>
        <finalName>${project.artifactId}</finalName>
    </build>

    <parent>
        <groupId>com.effectivcrm</groupId>
        <artifactId>parent</artifactId>
        <version>0.0.2</version>
    </parent>
</project>

 

Listing 2 - ecrm/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/maven-v4_0_0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <artifactId>ecrm</artifactId>
    <packaging>war</packaging>

    <name>ecrm</name>
    <url>http://maven.apache.org</url>

    <!-- ~~~~~~~~~~~~ -->
    <!-- DEPENDENCIES -->
    <!-- ~~~~~~~~~~~~ -->
    <dependencies>
        <dependency>
            <groupId>${project.groupId}</groupId>
            <artifactId>view</artifactId>
            <version>${project.version}</version>
        </dependency>
    </dependencies>

    <build>
        <finalName>${project.artifactId}</finalName>
    </build>

    <parent>
        <groupId>com.effectivcrm</groupId>
        <artifactId>parent</artifactId>
        <version>0.0.2</version>
    </parent>
</project>

 

Listing 3 - view/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>

  <artifactId>view</artifactId>
  <packaging>jar</packaging>

  <name>view</name>
  <url>http://maven.apache.org</url>

  <properties>
    <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
  </properties>

  <dependencies>

  </dependencies>

  <parent>
        <groupId>com.effectivcrm</groupId>
        <artifactId>parent</artifactId>
        <version>0.0.2</version>
    </parent>

</project>

Update - separating the controller

Following on our trail to create modular application, its time to move the controller to a different module / project. Thanks to maven this is very easy we can create another project with quickstart archetype named controller.Now we move the controller Java class to this project under com.effectivcrm.controller package. Also I will tweak the controller/pom.xml to include it as a child project. We also introduce a spring configuration file spring-controller-config.xml to include module specific Spring configuration for the controllers. Since the controller package scanning is moved to the new Spring configuration it has to be removed from the spring-web-config.xml. I will rename that to view/spring-view-config. Last but not the least we need to include the new project as parent module and depdency in ecrm project the aggregator.

Update - fixing the welcome page

Last but not the least we will solve the problem with welcome file and redirect to first / guest page. Unfortunately there is problem with Tomcat (or is this a feature? I do not know). So what I do is I will delete this index.jsp and remove the welcome file entry in web.xml. I will not add an entry in the controller to handle request mapping to / and pass it to the sign in page. The modifided code base is now available in the trunk.

Update - The missing log4j configuration

Well I missed the log4j configuration file. Actually my Tomcat had one so I had no problem. Note that the log4j is not residing inside my war / classpath. I have externalized it to load from a specific location inside Tomcat. This is probably not the world's best log4j.xml. I will progressively enhance it as we move forward to cater to different needs.  I have uploaded the same in the conf folder of svn/trunk.

Update - resources from classpath

I also want the resources to be loaded in a modular way. Hence I moved them to src/main/resources/META-INF/assets folder of view project. Accordingly I have changed the resource configuration in sping-view-config.xml file as shown in the snippet below:

 

<mvc:resources location="classpath:/META-INF/assets/img/" mapping="/assets/img/" />
<mvc:resources location="classpath:/META-INF/assets/css/" mapping="/assets/css/" />
<mvc:resources location="classpath:/META-INF/assets/js/" mapping="/assets/js/**" />

SVN Location - http://code.google.com/p/spring-modular/source/browse/

Related articles, courtesy of Zemanta:

• Maven Best Practices
• Cobertura and Maven: Code Coverage for Integration and Unit Tests
• Spring: Using @Configurable to configure objects created outside of spring context.
• Apache Camel deployment modes