domingo, marzo 27, 2011

A Te Che Sei Il Mio Grande Amore Ed Mio Amore Grande

Maven Verifier Plugin, is a Maven Plugin that is used for verifying the existence of certain conditions into files content. These conditions are expressed in form of regular expression, so if regular expression is matched in defined resources content, no error is showed, if not, build fails and error message is shown indicating which file does not matches the given expression.

Why I find this plugin useful? Usually my projects have three execution environments, one for unit testing, another for integration/acceptance test and production one. As you can imagine, each one has its configuration, like database configuration. Each environment has a different database, for example unit testing has a HSQL engine, while integration and production have a PostgreSQL. For dealing with that problem I usually create three different Spring files, each one loading required properties, and depending on environment, the applicationContext is modified for importing required resources. Let's look another example, in my work, I develop planners for instruments, in integration tests, an emulator is used, while in acceptance tests and production, as you can imagine we are using a real instrument. For that reason, we must inject into our business objects, which driver to use (emulator driver or real driver), and as you can imagine two spring files are created and are imported into application context depending on the stage of building.

The problem with changing importing files in applicationContext depending on environment, resides that implies a manual human process, and because it is human, an error can occurs and delivery a version with incorrect configured application context. Meanwhile Spring Framework 3.1 is not released as stable version (Spring Profiles would resolve that problem), Maven Verifier Plugin can help us to avoid that problem.

In our Continuous Integration System, one of our steps before releasing a version is check that all configuration files are configured with correct values, keep in mind that I have showed only two examples, but some other values are changed between development environment and production environment, like time constants, file locations, log level ... Thanks of that plugin this checking procedure is executed automatically.

Let's see an example:

First of all pom.xml must be configured for using Maven Verifier Plugin:

<verificationFile&gt; tag is where you configure which files should be verified and which rules should be applied.

And verifications-rules.xml:

In this example we are verifying that property-placeholder defined in applicationContext.xml are loading properties from META-INF/spring and not from any other location. Same approach can be used for verifying injected beans, constants, log level ... case that any verification does not matches, the build result would be a fail.

Although I always though myself "hey men this could not happen to me", one day, and you don't know whyhappens, and you upload code not correctly configured, and when VVT department starts verifications, project starts to crash, and then all test protocol should be cancelled, you must change one line, upload one line change to repository, re-deploy all application, and start again.

Since that day, I always create a regular expression for assuring that when my code is deployed for production, all configuration files contains correct values.

When Spring Framework 3.1 sees the light all will be different, meanwhile and for legacy code, try Maven Verifier Plugin.

3 comentarios:

littlealan dijo...

Nice sharing.
And we would like to verify that, after resources filtering, all the config files in a specific directory are substituted with proper values instead of leaving some placeholder like ${xxx} in the file. Could you share how we can do this with the maven verifier plugin? seems it have to specify the file one by one

Alex dijo...

Hi Alan, I have never used maven verifier with directories, but reading maven verifier documentation is seems like also supports directories as location.

And then in contains you should only create a regular expression that checks that no ${..} is present on document.

lalooth dijo...

s6y46e7c79 g1f66q0x43 h7q48p8z74 g7i96f5r24 c1r89x1a72 q3f39k3k17