Tag Archives: maven

jsr166y and extra166y libraries on Maven

If you wish to use jsr166y (fork join) and extra166y (parallel arrays), normally available as jars at the concurrency interest site, through maven there is a mirror repository that has been set up that can be used as follows.

Milestone repository




Though bear in mind that fork join will be included in the eventual Java 7 release. Parallel arrays sadly won’t be but at least they are available separately.

Compiling Java 1.6 projects using Maven on Mac OS X

The following maven pom file configuration works on Windows and Linux but not on Mac OS X.


The error that occurs is as follows.

Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation failure
Failure executing javac, but could not parse the error:
javac: invalid target release: 1.6

The reason is that the following environment variable isn’t set by default.

export JAVA_HOME="/System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home"

You can declare this either as a one time export in your current shell above, in /etc/profile as I normally do or in any other startup file of your choice. Afterwards be sure to refresh your shell before you try again. This can be done either by closing your current terminal window and opening a new one or by sourcing whichever file you’ve put the above information into.

source /etc/profile

In order to make sure that it has taken effect one can output it in the shell as follows.


If it shows nothing then the shell has not picked up your change.

If your tomcat had already been started prior to setting the environment variable then don’t forget to restart it in the new shell otherwise you will get the following error on startup when deploying your maven application.

Caused by: java.lang.UnsupportedClassVersionError: Bad version number in .class file (unable to load class service.ServiceImpl)
	at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:1851)
	at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:890)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1354)
	at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1233)
	at org.springframework.util.ClassUtils.forName(ClassUtils.java:211)
	at org.springframework.beans.factory.support.AbstractBeanDefinition.resolveBeanClass(AbstractBeanDefinition.java:385)
	at org.springframework.beans.factory.support.AbstractBeanFactory.resolveBeanClass(AbstractBeanFactory.java:1138)
	... 40 more

Check that your compiler and loader are using the same version of Java.

Spring AOP timing aspect

At some point or another everyone writes a timing aspect. It’s simple yet fun. Here’s mine. This is a timing aspect with a small difference. There exists an annotation called @Timed and you can apply that annotation at a class level or method level and accordingly the invocations shall be timed and the output printed to stdout. Although it is intended to be illustrative to a degree it hopefully offers some utility value also.


The following aspect acts on annotated classes and methods and times invocations producing output to stdout (which can be changed easily to a logger). In the background it uses Spring AOP driven by jdk proxies or cglib proxies depending on what the attribute proxy-target-class is set to in the spring xml.

Continue reading

Maven dependency graph visualisation in M2Eclipse

M2Eclipse has sure come a long way since I used it a few months back. To my surprise when I accidentally clicked the ‘Dependency graph’ tab on the pom editor the following appeared on my screen. Below is a small region of the graph – the full thing was too big even for my dual monitor setup. Click for slightly larger version. Take that ant :p Can IvyDE do that? 🙂

I have to say that I’m a little partial to maven even though ant is faster. I believe in reusing the wheel rather than reinventing it. I believe in convention over configuration. I believe in making 90% of the most commonly performed tasks easier to carry out through a rich and extensive feature set. I believe in higher level abstractions rather than simply providing low level building blocks. As an estemeed colleague of mine once said “It’s all about abstractions – if we didn’t have any abstractions we’d still be programming in assembler”. These are all the same characteristics that are possessed by Spring. I say all this however after finding out today that the rather large organisation that I’m currently working within evaluated maven some time back and chose to go with ivy instead. The reason? It was easier to integrate with existing infrastructure and this is a harsh reality of commerce – sometimes the feature set or being revolutionary or being free isn’t enough – sometimes legacy wins.

REST service example using CXF 2.2, JAX-RS 1.0, JAXB and Spring

In the modern day transition from a service oriented architecture to a resource oriented architecture the tools are only just catching up. Here’s a very brief and simple example of a REST service using CXF 2.2-SNAPSHOT, JAX-RS 1.0 and Spring 2.5.6. A few key points to note are as below.

  • The maven pom file imports a cxf jax-rs bundle which in turn imports all prerequisites – this saves individual cxf imports.
  • The getUsers() call demonstrates a rather unorthodox use of a dto as a replacement for a standard collection due to the fact that jaxb cannot handle collections as first class citizens.
  • A snapshot version (2.2) is being used of CXF which supports the final version of JAX-RS (1.0) whereas CXF 2.1.x supports only JAX-RS 0.8.
  • Annotations have been applied to the implementation but can be applied to the interface.
  • Annotations are inherited from interface to implementation and from class level to method level and can be overridden at method level.

Continue reading

Java project structural best practices

The structure of a java project has gone through some transitions in time. Here are some conventional examples.

Basic project

Here is a simple java project created in eclipse for basic needs. Although this is lightweight and simple it offers no place to put resources.

|-- bin
`-- src

Ant web project

Here is the legacy ant project layout before maven came along. It provides a place to put resources. However the problem is that if you put stuff in WEB-INF then it is not classpath accessible and, specific to eclipse, you cannot add WEB-INF as a source folder to add it to your editor classpath because it is nested in your output folder of WEB-INF/classes/.

|-- src
|-- tests
`-- webapp
    `-- WEB-INF
        `-- classes

Basic maven project

This is the standard maven layout and provides clean separation of every distinct responsibility of a project structure. It is very well defined and has no classpath problems and is my favourite.

|-- pom.xml
|-- src
|   |-- main
|   |   |-- java
|   |   |-- resources
|   |   `-- webapp
|   |       `-- WEB-INF
|   `-- test
|       |-- java
|       `-- resources
`-- target
    |-- classes
    `-- test-classes

Advanced maven project

The advanced maven project structure is offered by M2Eclipse, the eclipse plugin, and has one advantage over the previous structure. It offers different output directories for eclipse and command line. This is useful when building in editor and command line and you don’t want them to conflict, clear or overwrite each other in the output directory. This helps also with setting editors and build tools to work independently if their settings differ.

|-- pom.xml
|-- src
|   |-- main
|   |   |-- java
|   |   `-- resources
|   `-- test
|       |-- java
|       `-- resources
|-- target
|   |-- classes
|   `-- test-classes
`-- target-eclipse
    |-- classes
    `-- test-classes

Best practices

So what must one consider when creating a new project structure? Sometimes the use of maven is not permitted either due to a legacy environment or due to a heavy investment in ant already. That is when it becomes necessary to think in terms of concepts and the pros and cons of different structures outside of the domain of specific build tools. The following are some recommendations to follow which make life a hell of a lot easier.

  • Separate sources from tests. Yes I have seen them both together and it is a very bad idea.
  • Separate resources from the output folder. This can take the shape of a resources/ folder by itself in its simplest form. The benefit of this is that it can be classpath accessible by your editor and your build tool and is not nested within your output folder and can therefore be added as a source folder within your editor. This also thereby provides a uniform classpath based access mechanism to all its contents independent of the tool used. The build tool can then be configured to copy its contents to the output folder.
  • Optionally have separate output directories for different tools. At times for example it is necessary for eclipse and ant to operate on the same project but independently and in isolation especially when you are testing your build environment with various different tools and settings. Most of the time this is unnecessary and so optional.
  • When accessing resources from your application always use classpath based paths relative to your classpath. Spring makes this dead easy by allowing various locator patterns that also interpret wildcards (classpath:, classpath*:, file:). If you are storing your resources in their own folder and that is added to the classpath then you can access its contents by using simply a slash. The build tool or editor will then copy your resources into the output folder where the classpath based access will continue to apply whether deployed or otherwise.
  • When using components (jars) in your application containing resources such as spring context files and property files allow the application to aggregate. The component should only ever provide config and resources and never load them. It should also never access the application to load application specific content. The end-user application is where the control should lie and the components should remain subordinate and not only because the same component may be used in more than one disparate application.
  • Use Spring to your benefit. Spring provides a uniform mechanism to load resources of different kinds. Use it instead of loading resources manually. Try to resist the temptation to innovate on the classpath and associated integration and build tools. Reinventing the wheel rarely pays off in a positive way in some common ground!
  • Standardise on your editor if possible (non-essential) and if using source control check in your editor project configuration. It makes new check outs far more informative as to the project structure and classpath entries. If omitted or ignored it has be reconfigured from scratch every time.

This was a blog post on a rather simplistic and basic note. However I felt it was worth a mention at least once as there will always be legacy projects out there in need of inspiration. Classpath problems are fundamental and if they exist they tend to impact the application as a whole and its components and cause prolonged heartache. It’s worth having a clearly defined and justified strategy to begin with so that later on down the line your app can grow and change with ease.