Nathan at Work

So Maven in eclipse is a great time saver (and waster); in that it wastes a tonne of time setting up and learning, but saves a tonne of time in the long run on team projects.

This weeks maven problems have been running suites of testng test when doing a maven build; the old pergen memory not set high enough faults; but this time setting the paremeters was a bit harder.

here’s the fix(es):

set pergen space for eclipse (3.4) higher:
- run eclipse from the command line with the options:

eclipse -vmargs -Xms1536m -Xmx1536m -XX:PermSize=1024m -XX:MaxPermSize=2048m


- give maven more memory

export MAVEN_OPTS="-Xms1536m -Xmx1536m -XX:PermSize=1024m -XX:MaxPermSize=2048m"


now the bit that took ages to figure out – the maven eclipse plugin runs testng test through surefire on the console and returns back output to eclipse, not only that but it’s run through a jar using a jre – so to give this instance of the jre more memory you need to:

1. Right Click ProjectName > Run As > Maven Build…
2. Goals: (one of install, deploy etc)
   install -e
3. JRE Tab > VM Arguments:
   -Xms1536m -Xmx1536m -XX:PermSize=1024m -XX:MaxPermSize=2048m

AFAIK this and only this will allocate enough memory for the the test suite to run

Joy

These are more for my own reference, but may well help any readers as well, specifically they relate to using maven with the maven plugin for eclipse.

Maven “Package”
Will deploy the application to you’re local target directory only.

Maven “Install”
Will deploy the application to you’re local target directory AND to you’re local .m2/repository

Ignoring test failures when building
Project -> Right Click -> Run As -> Maven Build…
“Goals” => package -Dmaven.test.failure.ignore=true
>Run
(swap package for you’re goal)

Skipping tests all together when building.
Project -> Right Click -> Run As -> Maven Build…
“Goals” => package -Dmaven.test.skip=true
>Run
(swap package for you’re goal)

Additional non java files are not deployed (needed properties, xml files, beans etc)
Project -> Right Click -> Run As -> Maven Clean
Eclipse File Menu -> Project -> Clean
then build again and all should be fixed.

I’ll add more to the list as I find them.

When deploying applications using apache maven you often run in to dependency issues, two conflicting jars and the wrong one being used.

I recently ran in to this one when trying to deploy a multi-project application we are building at kraya; basically hibernate and cxf both depend on slf4j-* jars; hibernate down in the domain model project was depending on a newer version and using the method org.slf4j.impl.JDK14LoggerAdapter.trace, however the final web app depended on apache cxf which used an older version 1.3.1 of slf4j, which didn’t have the trace method.

Ultimately this led to an exception when deploying, “java.lang.AbstractMethodError: org.slf4j.impl.JDK14LoggerAdapter.trace”

To fix was a case of going through the dependency hierarchy in the web apps pom, locating the conflict on slf4j then changing the pom’s to make everything depend on the newer version.

from the maven site:

Dependency mediation – this determines what version of a dependency will be used when multiple versions of an artifact are encountered. Currently, Maven 2.0 only supports using the “nearest definition” which means that it will use the version of the closest dependency to your project in the tree of dependencies.

Translated this means the higher a dependency is in the dependencies block of the pom, the more weight it is given. In our case the resolution was to move the DomainModel project (with the newer hibernate slf4j jar) to the top of the dependencies. This fixed one of the two conflicts, namely slf4j-api.

Next up was to go to the pom of another dependent project (in the pom above cxf) and add in the dependency for the latest 1.5.6 same 1.5.2 version of slf4j-jdk14 as hibernate.

Job done, and no old 1.3.1 slf4j get deployed; thus no exception.

joy, and simpler than I though.