When working on www.beertoplist.com I ran into a Maven problem, that is fairly common: Having a project that should be configured differently for different environments. That is for instance you want one configuration for development, one for test and one for production. I wanted a solution that allowed me to make changes to all kind of configuration files, for instance property files, Spring context files and Tomcat context files.

Poor solution

Googling on the problem I found that most people suggested that you should use a set of Maven profiles, one for each environment. So when you want to build the project for test environment you enable the test profile and get all the test configuration. At first glance this might seem like a good solution, but there is a major problem with this solution.

When you have your artifact, how do tell which environment it is configured for? Even worse what if you forget to enable the production profile when releasing or maybe enable the test profile instead. Then you have released a test version of the project and there is no way you can tell except for checking the details in the artifact. Further more you commonly want to deploy the released version to a test environment, but you can not do that out of the box, because the released artifact in the Maven repository is configured for production (if you enabled the right profile). Thus you need to check out the release tag and build a new version with the test profile enabled. Now you end up with two files with the same name and version, that are configured differently. Not a very appealing solution.

My solution

My suggestion is to instead let Maven build one artifact for each configuration and label them accordingly, so when looking at a specific version in the Maven repository you find, one development artifact, one test artifact and one production artifact, each clearly labeled. Then you never run into the problems listed above. So how can we accomplish this?

Maven have the concept of classifiers. This is a suffix that is appended to the name of the artifact to distinguish it from the main artifact. This is used for instance by the source plugin that creates a source jar file for a Maven project, resulting in a file with the name <artifact id>-<version>-sources.jar. The classifier for this file is "sources". The same concept can be used to build a development, a test and a production artifact, which is the solution I choose in www.beertoplist.com.

I decided to put all the environment specific configuration in a special source tree, with the following structure:

+-src/
  +-env/
    +-dev/
    +-test/
    +-prod/

Then I configured the maven-war-plugin to have three different executions (the default plus two extra), one for each environment, producing three different war files: beer-1.0-dev.war, beer-1.0-test.war and beer-1.0-prod.war. Each of these configurations used the standard output files from the project and then copied the content from the corresponding src/env/ directory on to the output files, enabling an override file to be placed in the corresponding src/env/ directory. It also supported copying a full tree structure into the output directory. Thus if you for instance wanted to replace the web.xml in test you simply created the following directory:

src/env/test/WEB-INF/

and placed your test specific web.xml in this directory and if you wanted to override a db.property file placed in the classpath root directory for the test environment you created the following directory:

src/env/test/WEB-INF/classes

and placed your test specific db.property file in this directory.

I kept the src/main directory configured for development environment. The reason for this was to be able to use the maven-jetty-plugin without any extra configuration.

Configuration

Below you find the maven-war-plugin configuration that I used to accomplish this:

<plugin>
  <artifactId>maven-war-plugin</artifactId>
  <configuration>
    <classifier>prod</classifier>
    <webappDirectory>${project.build.directory}/${project.build.finalName}-prod</webappDirectory>
    <webResources>
      <resource>
        <directory>src/env/prod</directory>
      </resource>
    </webResources>
  </configuration>
  <executions>
    <execution>
      <id>package-test</id>
      <phase>package</phase>
      <configuration>
        <classifier>test</classifier>
        <webappDirectory>${project.build.directory}/${project.build.finalName}-test</webappDirectory>
        <webResources>
          <resource>
            <directory>src/env/test</directory>
          </resource>
        </webResources>
      </configuration>
      <goals>
        <goal>war</goal>
      </goals>
    </execution>
    <execution>
      <id>package-dev</id>
      <phase>package</phase>
      <configuration>
        <classifier>dev</classifier>
        <webappDirectory>${project.build.directory}/${project.build.finalName}-dev</webappDirectory>
        <webResources>
          <resource>
            <directory>src/env/dev</directory>
          </resource>
        </webResources>
      </configuration>
      <goals>
        <goal>war</goal>
      </goals>
    </execution>
  </executions>
</plugin>

What you really want is to have the midlet write the log to your development PC instantaneously and free of charge, then you can log whatever you want to pinpoint your bug. This could be accomplished by logging over Bluetooth. Previously you had to write your own code to handle the logging and Bluetooth communication as well as a server to which the midlet connects and sends the log messages, but now there is a powerful logging framework for Java ME that offers this support out of the box. The framework is MicroLog and is open source under the Apache Software License, so it is free to use as you see fit. MicroLog can be configured with one or more appenders that takes care of the logging messages and sends them to the right destination and each appender can have its own formatter to format the messages appropriately. This is very similar to log4j, so if you have used log4j before, MicroLog is very easy to learn. If you are using Maven 2 you will be happy to know that MicroLog is built using Maven 2 and is available in a public repository.

Setting up MicroLog to use Bluetooth and log to your PC is simple. It only requires that you setup your Logger:

private final static Logger log = Logger.getLogger(TestMidlet.class);

and that you configure it to use a BluetoothSerialAppender, which is done like this:

log.addAppender(new BluetoothSerialAppender());

Now your midlet is all set to start logging over Bluetooth. For a full midlet example see the following code:

package se.jayway.me;

import javax.microedition.lcdui.Command;
import javax.microedition.lcdui.CommandListener;
import javax.microedition.lcdui.Display;
import javax.microedition.lcdui.Displayable;
import javax.microedition.lcdui.TextBox;
import javax.microedition.midlet.MIDlet;
import javax.microedition.midlet.MIDletStateChangeException;

import net.sf.microlog.Logger;
import net.sf.microlog.bluetooth.BluetoothSerialAppender;

public class TestMidlet extends MIDlet
{

	private final static Logger log = Logger.getLogger(TestMidlet.class);

	public TestMidlet()
	{
		configureMicroLog();
	}

	protected void destroyApp(boolean arg0) throws MIDletStateChangeException
	{
		log.info("Destroying application...");
	}

	protected void pauseApp()
	{
		log.info("Pausing application...");
	}

	protected void startApp() throws MIDletStateChangeException
	{
		log.info("Starting application...");
		final TextBox textBox = new TextBox("Text", "My text", 100, 0);
		textBox.addCommand(new Command("Log", Command.SCREEN, 0));
		textBox.setCommandListener(new CommandListener() {
			private int counter;

			public void commandAction(Command c, Displayable d)
			{
				log.debug("You clicked " + counter++);
				log.debug(textBox.getString());
			}
		});
		Display.getDisplay(this).setCurrent(textBox);
	}

	private void configureMicroLog()
	{
		log.addAppender(new BluetoothSerialAppender());
	}
}

Build and deploy this midlet to your Bluetooth enabled device, supporting JSR-82, the Bluetooth API and make sure that Bluetooth is turned on.

Next you need to get the Bluetooth server that will receive and print the logging messages to standard out. The server is also available in a public Maven repository. Just download the version that ends with -jar-with-dependencies.jar. This file contains all its dependencies. Now make sure that your Bluetooth unit is on and discoverable on your PC. Then start the server with the following command:

java -cp microlog-servers-1.1.0-SNAPSHOT-jar-with-dependencies.jar net.sf.microlog.server.btspp.MicrologBtsppServer

You might have to change the jar file name if it is not the same as the one you downloaded, then just replace it with the file name of your own microlog-server jar file.

The server starts up and registers a logging service with a unique UUID that the phone will try to locate and connect to. Now start the midlet and see how it will start logging over the Bluetooth connection.

The first phone I tested was a SonyEricsson C905 and it worked perfectly from the start. Then I tried to use a SonyEricsson P990i and for some reason it failed to locate the logging server with the unique UUID. I was unable to determine the reason why it failed to locate the service, so instead I added support to the BluetoothSerialAppender to specify the url of the Bluetooth logger server. Using this and setting the server url to my PC it connected flawlessly to it and started logging. So if you experience problems when your midlet connects to the PC or if you are using multiple logger servers within the Bluetooth range of your device try specifying the server url that the BluetoothSerialAppender should connect to. The url of the server is shown when starting the logger server. This url does however contain a channel that is not possible to determine through the used API's, but it does start on 1 and increases. For each session I always got the same channel and it was only the next day that it changed and I got channel 2 instead, so try with 1 to start with and if that does not work increase it by one and try again. It will most likely work first or second time.

Now you are free to log as much as you want and do not have to restrict your logging during the development phase of your project. Neither is there a reason for writing your own Bluetooth logger, just use MicroLog.