Friday, September 7, 2012

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/

No comments:

Post a Comment