<plugin>
	<artifactId>maven-dependency-plugin</artifactId>
	<executions>
		<execution>
			<id>copy</id>
			<phase>process-sources</phase>
			<goals>
				<goal>copy</goal>
			</goals>
			<configuration>
				<artifactItems>
					<artifactItem>
						<groupId>org.springframework</groupId>
						<artifactId>spring-instrument</artifactId>
						<version>3.0.3.RELEASE</version>
					</artifactItem>
				</artifactItems>
			</configuration>
		</execution>
	</executions>
</plugin>

We have to pass in the weaving agent to surefire.

<plugin>
	<artifactId>maven-surefire-plugin</artifactId>
	<configuration>
		<argLine>-javaagent:${project.build.directory}/dependency/spring-instrument-3.0.3.RELEASE.jar</argLine>
	</configuration>
</plugin>

That tool performs the following steps

1. Detect the current software version from the artifact metadata that is embedded into any Maven-built artifact
2. Query Nexus for available artifacts for the installed software (identified by Maven groupId and artifactId).
3. Test if any of the available artfacts has a version number higher than the installed one
4. If a newer version is available then download it
5. Move the new version to the target directory (e.g. the deployment folder of the application server)

The Nexus REST url for a simple query for some artifact looks like http://localhost/nexus/service/local/data_index/repositories/releases/content?q=commons-lang. This query asks for the commons-lang artifact from the releases repository.

More URL schemes are documented here and there.

The result from this query is like (only the latest versions are included for brevity):

<?xml version="1.0" encoding="UTF-8"?>

<search-results>
	<totalCount>5</totalCount>
	<from>-1</from>
	<count>-1</count>
	<tooManyResults>false</tooManyResults>
	<data>
		<artifact>

			<resourceURI>http://localhost/nexus/service/local/repositories/central/content/commons-lang/commons-lang/2.4/commons-lang-2.4.jar</resourceURI>
			<groupId>commons-lang</groupId>
			<artifactId>commons-lang</artifactId>
			<version>2.4</version>
			<packaging>jar</packaging>
			<extension>jar</extension>

			<repoId>central</repoId>
			<contextId>Maven Central (Cache)</contextId>
			<pomLink>http://localhost/nexus/service/local/artifact/maven/redirect?r=central&g=commons-lang&a=commons-lang&v=2.4&e=pom</pomLink>
			<artifactLink>http://localhost/nexus/service/local/artifact/maven/redirect?r=central&g=commons-lang&a=commons-lang&v=2.4&e=jar</artifactLink>

		</artifact>
		<artifact>
			<resourceURI>http://localhost/nexus/service/local/repositories/central/content/commons-lang/commons-lang/2.4/commons-lang-2.4-sources.jar</resourceURI>
			<groupId>commons-lang</groupId>
			<artifactId>commons-lang</artifactId>
			<version>2.4</version>
			<classifier>sources</classifier>

			<packaging>jar</packaging>
			<extension>jar</extension>
			<repoId>central</repoId>
			<contextId>Maven Central (Cache)</contextId>
			<pomLink></pomLink>
			<artifactLink>http://localhost/nexus/service/local/artifact/maven/redirect?r=central&g=commons-lang&a=commons-lang&v=2.4&e=jar&c=sources</artifactLink>

		</artifact>

	</data>
</search-results>

That only needs to be parsed using a SAX parser for extracting the most important elements. This is the Maven GAV, packaging, classifier, and the download url which are stored in a POJO. This POJO implements the algorithm for selecting the latest version by its compareTo method.

public class MavenArtifactMetadata implements Comparable<MavenArtifactMetadata> {
	private String groupId;
	private String artifactId;
	private String version;
	private String resourceURI;
	private String packaging;
	private String classifier;

	@Override
	public int compareTo(MavenArtifactMetadata o) {
		if (!this.groupId.equals(o.groupId) || !this.artifactId.equals(o.artifactId)) {
			return -1;
		}
		return versionCompareTo(o.version);
	}

	int versionCompareTo(String version) {
		Integer[] thatVersion = versionComponents(version);
		Integer[] thisVersion = versionComponents(this.version);
		int length = Math.min(thatVersion.length, thisVersion.length);
		for (int i = 0; i < length; i++) {
			if (thatVersion[i].equals(thisVersion[i])) {
				continue;
			}
			return thisVersion[i].compareTo(thatVersion[i]);
		}
		return thisVersion.length - thatVersion.length;
	}

	Integer[] versionComponents(String version) {
		String[] splitted = StringUtils.delimitedListToStringArray(version, ".");
		if (splitted.length>0 && splitted[splitted.length-1].endsWith("-SNAPSHOT")) {
			splitted[splitted.length-1]=splitted[splitted.length-1].replaceAll("-SNAPSHOT", "");
		}
		Integer[] components = new Integer[splitted.length];
		for (int i = 0; i < splitted.length; i++) {
			components[i] = (Integer.valueOf(splitted[i]));
		}
		return components;
	}
}

While implementing the download part I had learned an important lesson. For downloading and moving large files it is much more efficient to use the Java NIO API.

So, I have implemented a fairly generic servlet that is able to provide almost any servlet request information for an active HTTP request. This servlet accepts a set of SpEL expressions (SpEL will be available with Spring 3.0) which are parsed and evaluated.
Finally it produces the evaluation results as MDC variables through the org.slf4j.MDC api (So I guess that might be usable for log4j as well).

	slf4jmdc
	at...SpringExpressionSlf4jMdcRequestFilter
	
mdcKeyExpression
contextPath=${request.contextPath};username=${request.userPrincipal?.name}
	

@Override
protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain filterChain) throws ServletException, IOException {
	StandardEvaluationContext context = new StandardEvaluationContext(new RootObject(request));
	ExpressionParser parser = new SpelExpressionParser();

	String[] mdc = StringUtils.delimitedListToStringArray(mdcKeyExpression, ";");
	Properties expressions = StringUtils.splitArrayElementsIntoProperties(mdc, "=");

	Enumeration keyNames = expressions.propertyNames();
	while (keyNames.hasMoreElements()) {
		String key = keyNames.nextElement().toString();
		try {
			Expression exp = parser.parseExpression(expressions.getProperty(key), new TemplateParserContext());
			Object value = exp.getValue(context);
			if (value != null) {
				MDC.put(key, value.toString());
			}
		} catch (ParseException e) {
			LOGGER.error("Parsing expression", e);
		}
	}

	try {
		filterChain.doFilter(request, response);
	} finally {
		while (keyNames.hasMoreElements()) {
			MDC.remove(keyNames.nextElement().toString());
		}
	}
}

This servlet can be used about anywhere MDC variables are needed!

On one side it is good to see a unique naming for all of the spring + subproject artifacts. But for those of you starting to migrate existing projects this causes a few headaches. Everything is fine as long as you can get all of your favourite libraries from one of the SpringSpource bundle repositories

	
		SpringSource Enterprise Bundle Repository - External Bundle Milestones
		http://repository.springsource.com/maven/bundles/milestone
	
	
		SpringSource Enterprise Bundle Repository - SpringSource Bundle Releases
		http://repository.springsource.com/maven/bundles/release
	
	
		SpringSource Enterprise Bundle Repository - External Bundle Releases
		http://repository.springsource.com/maven/bundles/external
	

Fortunately they also provide a really helpful tool for searching their repositories.

But sometimes you won’t find your favourite ones and need to fall back to non-bundle style artifacts from non-Springsource repositories.
And here is the trouble: SpringSource is renaming the Maven artifactId for all of the bundles stored in their repositories (e.g. com.springsource.org.apache.commons.logging is the bundle equivalent of org.apache.commons.logging).

So let’s say you depend on artifact A that comes from the bundle repository (that depends on logging) and also depend on artifact B that comes from the standard maven repository (and also dependes on logging).
This will end up with a 2 dependencies to the logging artifact and Maven will not be able to distinguish since they have a different artifactId.

To resolve that, start adding dependency exclusions and dependencies for first level transitive dependencies.

I’m showing an example for the hades project that actually has a bug in their dependency description.

	org.synyx.hades
	org.synyx.hades
	1.0
	
		
			org.aspectj
			aspectjrt
		
	


	org.aspectj
	com.springsource.org.aspectj.runtime
	1.6.1

Anyway here is how to fix it. Let’s say we have a web project A and a utility project B. You face the situation that project B does not show up as JavaEE module dependency. Open B in the navigator view (so you can see all the metadata files .project, .settings/… etc.).
Look for a file .settings/org.eclipse.wst.common.component! Does it exist? If no just create it, its contents should be like

Next check the .project file

	PROJECTNAME
	

	
	
		
			org.eclipse.wst.common.project.facet.core.builder
			
			
		
		
			org.eclipse.jdt.core.javabuilder
			
			
		
		
			org.maven.ide.eclipse.maven2Builder
			
			
		
		
			org.eclipse.wst.validation.validationbuilder
			
			
		
	
	
		org.eclipse.jdt.core.javanature
		org.maven.ide.eclipse.maven2Nature
		org.eclipse.jem.workbench.JavaEMFNature
		org.eclipse.wst.common.project.facet.core.nature
		org.eclipse.wst.common.modulecore.ModuleCoreNature
	

In my case the file was missing some builders (should not be relevant for the bug)

• org.maven.ide.eclipse.maven2Builder
• org.eclipse.wst.validation.validationbuilder

and some natures (these really hurt)

• org.eclipse.wst.common.modulecore.ModuleCoreNature
• org.eclipse.jem.workbench.JavaEMFNature

	javax.el
	el-api
	1.2
	provided



	javax.el
	el-ri
	1.2
	provided

So I would pull these file into my web project every time I create a new one and update these files as new tango version are released. This is not very handy as it is hard to synchronize these icons. On top of that code repository operations really slow down when checking out from or committing to the repository (just like it is with jars in the WEB-INF/lib folder).

As I have used Maven now for a while I had the idea of creating a kind of icon project that can be included in any web application just like an ordinary dependeny. This project only contains a project descriptor (pom.xml) which declares it as a project of type war. Further it includes the tango icons in the folder images/tango
plus a WEB-INF/web.xml (without any specific configuration, pretty much empty).
Any project that requires tango dektop icons just declares a maven dependency to this icon project. Any time this project is packaged (as a war file) Maven automatically unpacks the icon project into the packaged project and thus makes sure that it is up to date.

         com.example.projects
         tango-desktop-icons
         1.0-SNAPSHOT
         war
         runtime

For working within an IDE it is sufficient to perform the Maven command war:inplace to unpack the icon project into the project workspace!

This is called WAR overlaying!

This is extremely handy when using profiles for example to switch dependencies between a set of JSF 1.1 or JSF 1.2 libraries. Only with a twinkle I could change the classpath definition for any project. Ok so far this is nice.

For server development I’m working with the WTP plugin which makes handling a server a bit easier. So, regarding my library dependencies I’d feel more comfortable if they were updated every time I started my server (and thus publish the latest project files to the server).

So, I updated my m2eclipse plugin to 0.0.11 and tried to mark the Maven Dependencies Library Container as a J2EE Dependency, restarted my Web Container and was really excited that finally this is supported now. This means all of my dependencies from pom.xml are actually deployed to the server.

• http://snapshots.repository.codehaus.org
• http://people.apache.org/repo/m2-snapshot-repository
• https://maven-repository.dev.java.net/