(3502) Module-based development with Spring and Maven 2

Technical long talk 50 min

Wednesday, 2008-06-25, 15:00 - 15:50, Arena 3

• Philipp H. Oser - ELCA Zurich (speaker)
• Martin Zeltner - ELCA (co-speaker)

Topics

• Software engineering lifecycle
• Java Development Kit & Runtime Environment and its development
• Real-world experiences and show cases

Abstract

Modularity belongs to the basic architectural best practices. Splitting your 
application in separate modules can reduce undesired coupling as well as lead to 
high cohesion, reduce complexity, simplify team development, and decrease 
execution size by using only the required modules. 

This talks presents how we combine existing technologies (Spring and Maven 2) to 
get a seamless module support for the development, test and runtime of Java 
applications. Maven is concerned with build time aspects, Spring is concerned 
with run time aspects and there are some shared aspects that concern both. A 
developer can thus define in his module what the module shall do during 
development, test and runtime. This leads to better separation of concerns as 
each module can focus on its aspects and is less bothered by aspects of other 
modules. 
We argue that to realize the full potential, only combining plain Maven 2 and 
Spring is not sufficient and discuss what to add. The module support is 
implemented and freely available in the open source EL4J project 
(http://EL4J.sf.net).

Our modules contain the following:
-	Code
-	Dependencies on other modules
-	Application configuration: this includes mandatory configuration and 
configuration that shall only be activated in certain contexts 
-	Metadata about building, deployment, use in different environments (e.g., 
databases or application servers) and other aspects
-	Automated tests for the code

Writing a new application then means writing a new module and adding all 
required modules by simply making a dependency to them. The new application then 
automatically gets the code, the dependencies, default configuration and the 
other module's metadata. In case the new application needs to change the default 
of another module it depends on, this is easily possible. 



What are some benefits of such seamless modules?
-	Automatic launch and/or deploy of an application, with all included modules 
and their configuration parameters. This step may include the previous launch of 
an application server or an embedded database.
-	Automatic database script execution. For create script executions this should 
e.g., work in the order from the most generic module to the most specific 
module; for delete script executions in the inverse order.
-	Predefined basic configurations make modules more easily usable out of the 
box. Each module can specify basic configuration and modules using these modules 
can either reuse the specification or adapt them. This requires (1) mechanisms 
for incremental specification of configuration (2) defined ordering of the 
resources (to ensure consistent overriding), and (3) a way to automatically 
locate default configuration.
-	Simplified addition of certain aspects such as performance measurements to a 
module. Such aspects are implemented as a module. To add the aspect to an 
existing application, just add a dependency to the module implementing the 
aspect. The module's default configuration is automatically activated, and the 
build support enabled. An aspect is self-contained in a module, leading to 
higher cohesion. 
Concerns other than performance measurements that we implemented in this way are 
enabling publication of all configuration data via JMX, adding remoting to an 
application or security features.
-	Support for different environments (e.g. databases or applications servers) 
and their respective configuration parameters. Many of these parameters need to 
be shared between Maven (at build time) and Spring (at runtime). 
Most build systems support this in a basic way, but it's often desirable to have 
environment-data (such as db-scripts) for more than 1 environment (e.g. oracle 
and db2) in one module. This means fewer environment-specific binary modules.
-	Versions handling of a set of modules that allow that applications depend by 
default on the default version of other modules to ensure the use of a 
compatible set of module versions.
-	"Composite pattern for modules": a set of modules can be treated in 
the same way as a single module. This can be useful to work in a homogenous way 
on one or n modules (i.e. for reporting or testing).

70% of this vision is achieved through basic use of Spring and Maven 2, but to 
get to the full benefits, some additional usage patterns and mechanisms are 
required. We show how we have overcome the issues in our context. This 
includes:
-	A naming pattern for default and optional configuration files, a configuration 
file loading mechanisms allowing easily exclusion of some files, and a mechanism 
to complete existing configuration values.
-	Spring loads configuration resources from the classpath. As the ordering of 
resources in the Java classpath is not predictable in all contexts, we need to 
(1) include at build time dependency information in the manifest files of jar 
files to ensure correct resource loading order and (2) interpret this dependency 
information at runtime.
-	A tool for establishing the dependency graph of a set of modules. The order of 
the dependencies can then be used for reporting or for establishing the 
execution order of database initialization scripts.
-	Avoiding that snapshot versions of maven plugins compromise the stability of 
builds.
-	For multi-environment support we need to share data between build- and 
runtime. A maven plugin and a naming convention support this.

Experience, limitations and discussions, including:
-	Experience using this module abstraction in several large projects. 
-	Differences between the execution environment of Maven 2 and Eclipse (lacking 
WAR overriding, jar vs. pure classes, environment variable replacement)
-	Comparison of this proven module abstraction with 2 currently emerging 
approaches: the strict runtime compartments of Spring's dynamic modules support 
(based on OSGi, currently RC1 is out) and the new Java Module System (JSR 277, 
available as an early draft).