Dependency Inversion in Software Configuration Management

An effective software project management will include a mandatory configuration management system, which manages among others the process for compiling, packaging, testing and deploying the software codes. In this context, the dependency inversion framework prototype presented in this and previous blogs is based on

• the Maven open source platform  for configuration management, and
• the maven-processor-plugin (Maven Plugin) for invoking the processing of dependency inversion annotations at appropriate build lifecycle phase.

As discussed in the last chapter, the annotation processor works on the byte codes of the classes to inject the necessary commands for the adaptation of the run-time behaviors. As a result, the processing of the annotations shall happen after the compilation phases, but before the packaging lifecycle phases.
An appropriate build phase for the processing of  dependency inversion annotations is the process-test-classes phase. At his stage, all classes, including the test classes are already compiled to byte code, while the testing phase is not yet started. Therefore it is possible to test the annotated codes in the unit test phases before packaging the software for integration tests.

List 6 shows a snippet from the pom.xml for the artifact that includes some extension classes for some new features. In this configuration, the corresponding annotation processor is applied by the annotation plugin at the process-test-classes phase. The modified byte codes are then used in later phases to package and deploy the software for tests and operations.

……
<build>
<plugins>
    <plugin>
      <groupId>org.bsc.maven</groupId>
      <artifactId>maven-processor-plugin</artifactId>
      <executions>
        <execution>
          <id>process</id>
          <goals>  <goal>process</goal>  </goals>
          <phase>process-test-classes</phase>
          <configuration>
            <processors>
               <!-- list of processors to use -->
               <processor>invframework.AnnotationProcessor</processor>
            </processors>
          </configuration> 
        </execution>
      </executions>
</plugin>
……
</plugins>
</build>
</dependencies>
  <dependency>
   <groupId>invframework-annotation</groupId>
   <artifactId>invframework-annotation-processor</artifactId>
   <version>0.5</version>
   <scope>compile</scope>
  </dependency>
 ……
</dependencies>
……

List 6: Maven Project pom.xml for Annotation Processing

As an example, the Maven command upon the corresponding project:
     mvn clean intall
will create the needed jar, war and sar files and also install them in the Maven repository for the deployment phase.

In our previous example, we have the base module for the login service and the new feature for counting the active sessions. Suppose the based module is implemented in artifact usermgr, while the extensions are positioned in another artifact loginextensions, we have two different configurations for deployment (e.g. ear) packaging as depicted in Figure 2.

Figure 2: Deployment Configurations

Depending the live requirements, an operation manager can decide to include or exclude the new extensions from the servers to be deployed.

E.g. if the capacity problem is solved and the limitation of concurrent sessions is no longer necessary, one can decide to re-deploy the server and switch back to the base deployment A by deleting the artifact loginextensions from the deployment dependency.

As can be seen in the example, new features can easily added to or deleted from the running servers using different deployment configurations - without changing the source code for the base modules and without overlapping the potentially conflicting responsibilities and focuses.

Next Page - Summary