First, I used the basic HTTP test setup. Now however, I needed Jetty to provide a HTTPS connector. For this to work, Jetty – just like any other webserver, such as apache – needs a server certificate and a private key in a keystore. To create the keystore, I simply followed the excellent Jetty SSL guide. Namingly, I did this (using Ubuntu, see the above link for alternatives):

openssl genrsa -des3 -out jetty.key
openssl req -new -x509 -key jetty.key -out jetty.crt
openssl pkcs12 -inkey jetty.key -in jetty.crt -export -out jetty.pkcs12
$JAVA_HOME/bin/keytool -importkeystore -srckeystore jetty.pkcs12 -srcstoretype PKCS12 -destkeystore keystore

Once I had the keystore set up, I placed it in the src/main/resources folder (the root of the classpath, in case you’re not a maven user) and extended the HttpTestServer like so:

import java.net.URL;

import org.junit.Ignore;
import org.mortbay.jetty.Connector;
import org.mortbay.jetty.security.SslSocketConnector;

/**
 * A test server for testing SSL requests.
 *
 * @author Olaf Otto
 */
@Ignore
public class SslTestServer extends HttpTestServer {
	private static final int HTTPS_PORT = 50443;

	public SslTestServer() {
	}

	public SslTestServer(String mockData) {
		super(mockData);
	}

	@Override
	protected void configureServer() {
		super.configureServer();
		Connector secureConnector = createSecureConnector();
		getServer().addConnector(secureConnector);
	}

	private Connector createSecureConnector() {
		SslSocketConnector connector = new SslSocketConnector();
		connector.setPort(HTTPS_PORT);
		URL keystoreUrl = getClass().getClassLoader().getResource("keystore");
		connector.setKeystore(keystoreUrl.getFile());
		connector.setKeyPassword("test");
		return connector;
	}

	public static void main(String[] args) {
		SslTestServer server = new SslTestServer();
		try {
			server.start();
		} catch (Exception e) {
			throw new RuntimeException(e);
		}
	}
}

(I added the @Ignore annotation as I placed the class in the test sources folder, though it’s not a test…)
You might use it in your JUnit-based test like so:

import org.junit.After;
import org.junit.Before;
import org.junit.Test;

/**
 * @author Olaf Otto
 */
public class MySslTest {
	private SslTestServer _server;

	@Before
	public void startServer() throws Exception {
		_server = new SslTestServer();
		_server.start();
	}

	@After
	public void stopServer() throws Exception {
		_server.stop();
	}

	@Test
	public void mySsltest() {
		_server.setMockResponseData("<xml>My client expects this response</xml>");
		// Perform tests on port 50443...
	}
}

Here is the whole package as a maven 2 project (including the keystore with a self-signed certificate). Download, unzip, and give it a try (mvn test).

As an alternative, one may simply replace the backend with a mock HTTP server that does one thing: deliver the expected webserver response – i.e. XML data – when called by the client. All you need to set this up is a HTTP server and a pre-recorded service response (quite often this comes with WS client specifications). If you don’t have this data, you can record it, for example using a proxy server in between your WS client and a real WS backend, or a tool such as wireshark.

The recorded XML response thus represents your assumptions against which you test the client. This makes your tests fast, lightweight and a lot better to understand.

Here is my Jetty-based test HTTP server:

package de.sysbsb.test;

import static javax.servlet.http.HttpServletResponse.SC_OK;
import static org.apache.commons.io.IOUtils.write;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.apache.commons.io.IOUtils;
import org.junit.Ignore;
import org.mortbay.jetty.Handler;
import org.mortbay.jetty.HttpConnection;
import org.mortbay.jetty.Request;
import org.mortbay.jetty.Server;
import org.mortbay.jetty.handler.AbstractHandler;

/**
 * A server for answering HTTP requests with test response data.
 *
 * @author Olaf Otto
 */
@Ignore
public class HttpTestServer {
	public static final int HTTP_PORT = 50036;

	private Server _server;
	private String _responseBody;
	private String _requestBody;
	private String _mockResponseData;

	public HttpTestServer() {
	}

	public HttpTestServer(String mockData) {
		setMockResponseData(mockData);
	}

	public void start() throws Exception {
		configureServer();
		startServer();
	}

	private void startServer() throws Exception {
		_server.start();
	}

	protected void configureServer() {
		_server = new Server(HTTP_PORT);
		_server.setHandler(getMockHandler());
	}

	/**
	 * Creates an {@link AbstractHandler handler} returning an arbitrary String as a response.
	 *
	 * @return never <code>null</code>.
	 */
	public Handler getMockHandler() {
		Handler handler = new AbstractHandler() {

			public void handle(String target, HttpServletRequest request, HttpServletResponse response, int dispatch) throws IOException, ServletException {
				Request baseRequest = request instanceof Request ? (Request) request : HttpConnection.getCurrentConnection().getRequest();
				setResponseBody(getMockResponseData());
				setRequestBody(IOUtils.toString(baseRequest.getInputStream()));
				response.setStatus(SC_OK);
				response.setContentType("text/xml;charset=utf-8");
				write(getResponseBody(), response.getOutputStream());
				baseRequest.setHandled(true);
			}
		};
		return handler;
	}

	public void stop() throws Exception {
		_server.stop();
	}

	public void setResponseBody(String responseBody) {
		_responseBody = responseBody;
	}

	public String getResponseBody() {
		return _responseBody;
	}

	public void setRequestBody(String requestBody) {
		_requestBody = requestBody;
	}

	public String getRequestBody() {
		return _requestBody;
	}

	public static void main(String[] args) {
		HttpTestServer server = new HttpTestServer();
		try {
			server.start();
		} catch (Exception e) {
			throw new RuntimeException(e);
		}
	}

	public void setMockResponseData(String mockResponseData) {
		_mockResponseData = mockResponseData;
	}

	public String getMockResponseData() {
		return _mockResponseData;
	}

	protected Server getServer() {
		return _server;
	}
}

You can use it in a JUnit test like so:

package de.sysbsb.test;

import java.io.IOException;
import java.io.InputStream;

import org.apache.commons.io.IOUtils;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;

/**
 * @author Olaf Otto
 */
public class MyClientTest {
	private HttpTestServer _server;

	@Before
	public void startTestServer() throws Exception {
		_server = new HttpTestServer();
		_server.start();
	}

	@After
	public void stopTestServer() throws Exception {
		_server.stop();
	}

	@Test
	public void someClientTest() throws IOException {
		_server.setMockResponseData("<xml><testdata>hello, world</testdata></xml>");
		// or as a much more elegant alternative:
		_server.setMockResponseData(getRecordedResponse("testdata.xml"));
		// run your client tests, using the HttpTestServer.HTTP_PORT
	}

	private String getRecordedResponse(String recordedResponseFile) throws IOException {
		InputStream testDataStream = getClass().getClassLoader().getResourceAsStream(recordedResponseFile);
		return IOUtils.toString(testDataStream);
	}
}

Here are is the HTTP test server and a JUnit test example as a maven 2 project.

This also means that mavens resource filtering is not very useful for individual assemblies, since you can only replace placeholders such as ${someValue} with the same value for all assemblies (since resources are only filtered once, using the active profile(s), for all assemblies).

You can, however, configure the maven assembly plugin to use individual filter property files for each assembly using the <execution> section of the plugin configuration, like so:

<plugin>
  <artifactId>maven-assembly-plugin</artifactId>

  <version>2.2-beta-5</version>
  <executions>
    <execution>
      <id>production</id>
      <goals>

        <goal>single</goal>
      </goals>
      <configuration>
        <filters>
          <filter>${project.basedir}/src/main/assembly/production.properties</filter>

        </filters>
        <finalName>${artifactId}-production-${version}</finalName>
        <ignoreDirFormatExtensions>true</ignoreDirFormatExtensions>
        <descriptors>
          <descriptor>src/main/assembly/assembly.xml</descriptor>

        </descriptors>
      </configuration>
      <phase>package</phase>
    </execution>
    <execution>

      <id>integration</id>
      <goals>
        <goal>single</goal>
      </goals>
      <configuration>

        <filters>
          <filter>${project.basedir}/src/main/assembly/integration.properties</filter>
        </filters>
        <finalName>${artifactId}-integration-${version}</finalName>
        <ignoreDirFormatExtensions>true</ignoreDirFormatExtensions>

        <descriptors>
          <descriptor>src/main/assembly/assembly.xml</descriptor>
        </descriptors>
      </configuration>
      <phase>package</phase>

    </execution>
  </executions>
</plugin>

This snippet uses the same assembly descriptor (you can use any assembly descriptor, actually) to build individual artifacts for production and integration. Note that the ${project.basedir}/ prefix is a workaround for MASSEMBLY-150 and is nedded to avoid a nasty Failed to create assembly: Error filtering file ... Error loading property file 'src/main/...' error when executing the mojo from outside the module directory (say, for instance, in a mvn release:prepare…).

Filtering must be enabled in the assembly descriptor, like so:

<?xml version="1.0" encoding="UTF-8"?>
<assembly xmlns="http://maven.apache.org/xsd/assembly"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

  xsi:schemaLocation="http://maven.apache.org/xsd/assembly http://maven.apache.org/xsd/assembly-1.1.1.xsd">
  ...
  <fileSets>
    <fileSet>
      <filtered>true</filtered>
      ...
    </fileSet>

  </fileSets>
</assembly>

Thanks to John Casey for suggesting this in MASSEMBLY-430!


[INFO] Executing: svn --non-interactive copy --file /tmp/...commit . https://subversion..../tags/...
[INFO] Working directory: ...
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Unable to tag SCM
Provider message:
The svn tag command failed.
Command output:
svn: Commit failed (details follow):
svn: File '...' already exists


If you do, you are using subversion 1.5.x which no longer supports tagging from a local working copy, thus causing the unfortunately very misleading error message.

This is a known issue of the subversion sourcecode management (SCM) and there is a simple workaround:

Use the latest 2.x snapshot version of the maven release plugin and configure it to use remote tagging (on the subversion server) rather than tagging from your local copy.

You can do so by

1.) Adding the apache snapshots repository to your plugin repositories list

    <pluginRepositories>
        <pluginRepository>
            <id>apache-snapshots</id>
            <name>Apache Snapshot Repository</name>
            <url>http://repository.apache.org/snapshots/</url>
            <snapshots>
                <enabled>true</enabled>
            </snapshots>
        </pluginRepository>
        ...
    </pluginRepositories>

2.) Configuring the release plugin’s version and tagging

        ...
        <build>
        ...
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-release-plugin</artifactId>
                    <version>2.0-beta-9-SNAPSHOT</version>
                    <configuration>
                        <tagBase>full url to the tags directory on the svn server</tagBase>
                        <!-- See http://jira.codehaus.org/browse/SCM-406 -->
                        <remoteTagging>true</remoteTagging>
                        <!-- Further non-mandatory but useful settings... -->
                        <preparationGoals>clean install</preparationGoals>
                        <autoVersionSubmodules>true</autoVersionSubmodules>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
        ...
        </build>
        ...

This fixed it for me.

Note: i had problems getting this to function with the scp:// protocol (provider) for my distribution repository. It seems logic, tough, that the choosen provider must support remote tagging, thus i choose the scpexe:// protocol (using a local scp executable) instead, that worked:

...
<distributionManagement>
<repository>
  <id>myReo</id>
  <name>myreo</name>
  <url>scpexe://...</url>
 </repository>
...
</distributionManagement>
...

Apparently, the upcoming 2.0 release of the maven-release-plugin will have remote tagging as default, so if you read this and the 2.0 version has been released, simply using it should do the job.

This is, however, a misunderstanding. mvnDebug is there to enable debugging of the maven process and not of the surefire execution – and disabling forking may have various side effects. One of those is the use of Java agents. When using agents, e.g. for loadtime-weaving in the Spring Framework, one often specifies a -javaagent: as a JVM argument for surefire:

<!-- See http://maven.apache.org/plugins/maven-surefire-plugin/ -->
	<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-surefire-plugin</artifactId>
	<configuration>
		<!--
			The following must be within one line of code, line breaks will
			cause surefire execution to fail.
		-->
		<argLine>-javaagent:/path/to/myagent.jar</argLine>
	</configuration>

Java agents however must be provided as an argument to the JVM when it starts – which is exactly what happens when surefire “forks”.
Thus: No forking, no agents, since the tests will be executed in the current jvm used to execute maven itself – and that one was not started with a -javaagent argument. In order to execute surefire tests and use agents, the forkMode must at least be “once” (-DforkMode=once).

Thus, leave the forking as it is, and enable remote debugging as described in the surefire plug-in documentation, i.e. without using mvnDebug:


mvn test -Dmaven.surefire.debug


Which will open a remote debugging port at localhost:5005 for the test execution – and use the agents.

This is not because continuum lacks memory, but because maven does – and running findbugs is a quite resource-hungry undertaking.
The following addition to the “mvn” executable (residing in your maven’s “bin” folder) should do (tested in the 2.0.8 release):

MAVEN_OPTS="-Xmx1024m -Xms128m -XX:MaxPermSize=512m".

I must admit that -Xmx1024m is rather generous, though. 256m or 512m might do for many cases, too.


org.apache.maven.continuum.execution.ContinuumBuildCancelledException: The build was cancelled

at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:214)
at org.apache.maven.continuum.execution.maven.m2.MavenTwoBuildExecutor.build(MavenTwoBuildExecutor.java:138)
at org.apache.maven.continuum.core.action.ExecuteBuilderContinuumAction.execute(ExecuteBuilderContinuumAction.java:118)
at org.apache.maven.continuum.buildcontroller.DefaultBuildController.performAction(DefaultBuildController.java:408)
at org.apache.maven.continuum.buildcontroller.DefaultBuildController.build(DefaultBuildController.java:147)
at org.apache.maven.continuum.buildcontroller.BuildProjectTaskExecutor.executeTask(BuildProjectTaskExecutor.java:50)
at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
at edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
at java.lang.Thread.run(Thread.java:619)
Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing external command, process killed.
at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:164)
at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:89)
at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:114)
at org.apache.maven.continuum.utils.shell.DefaultShellCommandHelper.executeShellCommand(DefaultShellCommandHelper.java:59)
at org.apache.maven.continuum.execution.AbstractBuildExecutor.executeShellCommand(AbstractBuildExecutor.java:202)
... 11 more
Caused by: java.lang.InterruptedException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:485)
at java.lang.UNIXProcess.waitFor(UNIXProcess.java:165)
at org.codehaus.plexus.util.cli.CommandLineUtils.executeCommandLine(CommandLineUtils.java:128)
... 15 more


The simple reason is: The build is taking longer than continuum allows it to take, and thus the execution is canceled.
The maximum amount of time a build may take is schedule-specific, and can thus be configured in the “schedules” view under “Administration”.

If you change the execution time, i would recommend to adapt the time between checks for new builds accordingly.

Here’s a screenshot showing the setting that worked for my maven project:

Unfortunately, such a setting usually does not contain a username, since this has to be provided by the actual team member connecting to version control.
Neither did i have any intention to configure a placeholder into the scm section, forcing the developers to mess with the maven settings.xml in order to provide their own username.

Luckily, after searching a while, i found a proper solution.
SSH allows an optional per-host specific username setting to be placed in a file called “config” located in the user’s .ssh directory, for example

File: ~/.ssh/config


Host my.host.name
User myusername


Thanks to Chad Humphries for posting the Solution on programming is hard.
It really wasn’t…

mvn-Vervollständigung unter Ubuntu 7.10 (Gutsy Gibbon)

Unter der ubuntu-Distribution 7.10 (Gutsy Gibbon) aktiviert man die autocompletion durch Anlegen einer completion-Datei im Verzeichnis /etc/bash_completion.d, beispielsweise mit folgenden Inhalt:

#!/bin/bash

_m2_make_goals()
{
  plugin=$1
  mojos=$2
  for mojo in $mojos
  do
    export goals="$goals $plugin:$mojo"
  done
}

_m2_complete()
{
  local cur goals

  COMPREPLY=()
  cur=${COMP_WORDS[COMP_CWORD]}
  goals='clean compile test install package deploy site'
  goals=$goals _m2_make_goals "eclipse" "eclipse"
  goals=$goals _m2_make_goals "idea" "idea"
  goals=$goals _m2_make_goals "project-info-reports" "dependencies"
  goals=$goals _m2_make_goals "assembly" "assembly"
  goals=$goals _m2_make_goals "plexus" "app bundle-application bundle-runtime descriptor runtime service"
  cur=`echo $cur | sed 's/\\\\//g'`
  COMPREPLY=($(compgen -W "${goals}" ${cur} | sed 's/\\\\//g') )
}

Quelle: Working more productively with bash 2.x/3.x

Wie das ganze für Windows und MAC eingerichtet wird, steht auf willcodeforbeer.