Posted by Erik Pragt around lunchtime: July 29th, 2008
The problem
What if you’re working with Maven, where you’ve got all your dependencies nicely organised, and now you decide to use any other piece of ‘classpath-aware’ software, like Fitnesse. The chances are that you’ll need to use the same classpath in Fitnesse as in Maven. A possible solution could be to maintain it by hand, but why not write a very small script for it to do it for you? My (very very very!) basic solution is to use a Groovy, because it’s easy to write, easy to read, and easy to use!
The solution
def pom = new XmlSlurper().parse("pom.xml")
pom.dependencies.dependency.each { dependency ->
println "!path \${mavenRepo}/${dependency.groupId}/${dependency.artifact
Id}/${dependency.version}/${dependency.artifactId}-${dependency.version}.jar"
}
Et voila: a very small script to keep track of the Maven dependencies and export them in a format which is suiteable for Fitnesse. Mind the ${maveRepo} though: it’s the name of a system property which has been supplied in the run.sh when starting Fitnesse, and points to your Maven repository (which is ${USER}/.m2/repository)
Well, I hope will make your life a little easier, and ofcourse you can do all kinds of nifty things with it, like turning it into a Maven plugin or something………
What about transitive dependencies and parent POMs ? When you’re simply slurping the xml, you won’t get the transitive and inherited dependencies so your fitnesse classpath might still cause problems.
I think Maven2 has support for embedding so maybe you could use that part of maven to read the POM.
What about using the manifest for this? Just include the depended jars in your fitnesse project jar manifest.
Hi Erik, thanks for the snippet. Like Age said we need transitive dependencies! Any change of a plugin version for Maven?
@Age: this is not the holy Grails ofcourse! It cannot even handle variables in versions, which some people like to declare. If you want to expand it to handle transitive dependencies (seems quite important) and parent poms (IMO, less import: just run the script twice), go ahead. I’m curious to see what you can come up with. Maybe ITR idea?
@Nanne: I didn’t think about using the Manifest, but it also has some complications, for example when having an executable Jar with all dependencies extracted in the executable jar. The Manifest won’t contain the dependencies then.
@Silvester: Ofcourse, when the sun stop shining, days will last 10 hours longer, etc, etc
. In other words: those chances are very slim!
We had a similar problem. We simply created a Maven plugin to getthe classpaths (test,compile, etc.) and construct the command line before launching our external program, treating dependecies the maven way.
I don’t think I still have the code
(( because it was so simple we just trashed it when we didn’t need it anymore. 
(
Emmanuel
[...] for a solution, the first hit that I got which addresses this problem is a blog by my fellow Xebian Erik Pragt. A drawback of his approach is that it does not handle transitive dependencies. Therefore, I found [...]