Posts filed under 'Maven'
Maven's Cobertura plugin in version 2.1 introduced a very annoying bug which makes the plugin useless. The generated HTML report always shows 100% line and branch coverage. The most recommended way to avoid this problem is to use version 2.0 of the plugin (see Maven Users mailing list). But that's not a solution for me as the maven plugin version 2.0 still uses cobertura 1.7 for report generation which lacks some nice features of the cobertura version 1.8 which is used by the maven plugin version 2.1.
If you have a look at the issue tracking page, there is already a solution for the bug report. It's not directly a bug of the maven plugin but more a bug of cobertura itself if you have a look on following issue. The fix is already in the source code repository and will be part of the 1.9 release of cobertura. If you can't wait until cobertura 1.9 is realeased. I prepared a cobertura artifact which is compiled from the sources of the subversion repository and works with the maven plugin version 2.1.
All you have to do is to download the patched Cobertura files unzip them in a folder. In the folder issue the following command:
XML:
-
mvn install:install-file -Dfile=cobertura-1.8.jar -DpomFile=cobertura-1.8.pom
to install them in the local repository. If you would like to install them in a remote repository:
XML:
-
mvn depoloy:deploy-file -Dfile=cobertura-1.8.jar -DpomFile=cobertura-1.8.pom
-
-DrepositoryId=<id-of-server-section-of-settings.xml> -Durl=<url-of-the-repositor-to-deploy>
Don't forget to change the version for the maven cobertura plugin to 2.1 in your pom! Then you will get such nice looking html reports about the code coverage for your project.
May 12th, 2007
Currently i am using Proximity in an enterprise environment as maven proxy and remote repository mirror. As i am not quite happy with this solution i am still searching for better solutions. My experience so far with the different maven 2 proxies:
- Archiva: Still alpha; not much documentation, needs to be built from source wich can be a little bit tricky ...
- Proximity: Works; slightly confusing i still do not understand the intention behind the separation of metadata and storage; hard to configure, a lot of spring configuration files have to be edited and of course there is no sufficient documentation
- m2proxy: Simple, a little bit too simple ...
All of the above proxies do not have the possibility to define access rights which may be important in enterprise environments.
Artifactory which was announced on the maven users mailing list at march the 4th seems to concentrate more on enterprise features:
- Enhanced security for controlling who can deploy/undeploy to where.
- Web based deployment, including extraction of the POM embedded in a deployed jar for a single transaction deployment of both a jar and its POM
- Optional authenticated download of artifacts from local repositories
The feature list sounds great but the live demo (username: guest, password: guest) did not impress me but i think it's worth to spend more time for research on it.
My personal conclusion for the moment is that Proximity is the only working maven 2 proxy which can be used in enterprise environments. Maybe Artifactory is an equal or even better alternative. I'll have a closer look at it and tell you about my experiences ...
March 15th, 2007
I am currently trying to get unit tests written in groovy running for a maven project. First i thought this would be easy going but it is definitely not. First i tried the groovy-maven-plugin version 1.0-alpha-1-SNAPSHOT from the 27th of February.
As i want to compile my groovy unit test to java byte code I just inserted following XML snippet to my parent pom.xml:
XML:
-
<plugin>
-
<groupId>org.codehaus.mojo</groupId>
-
<artifactId>groovy-maven-plugin</artifactId>
-
<version>1.0-alpha-1-SNAPSHOT</version>
-
<executions>
-
<execution>
-
<phase>test-compile</phase>
-
<goals>
-
<goal>compile</goal>
-
</goals>
-
</execution>
-
<configuration>
-
<sourceDirectories>
-
${project.testSourceRoots}
-
</sourceDirectories>
-
</configuration>
-
</executions>
-
</plugin>
This approach did not work. If i tried to run mvn test the plugin did not get executed and if i tried mvn groovy:compile maven said that it could not find the correct version for plugin org.apache.maven.plugins:groovy-maven-plugin. Huuh? Why is maven not considering the configured group id? After playing around for a while with this problem and without finding any solution I decided to try another approach.
After a short internet research i found the following guide about compiling groovy with maven 2.
XML:
-
<plugin>
-
<artifactId>maven-antrun-plugin</artifactId>
-
<executions>
-
<execution>
-
<id>test-compile</id>
-
<phase>test-compile</phase>
-
<configuration>
-
<tasks>
-
<taskdef name="groovyc" classname="org.codehaus.groovy.ant.Groovyc">
-
<classpath refid="maven.compile.classpath"/>
-
</taskdef>
-
<mkdir dir="${project.build.testOutputDirectory}"/>
-
<groovyc destdir="${project.build.testOutputDirectory}"
-
srcdir="${basedir}/src/test/java/" listfiles="true">
-
<classpath refid="maven.test.classpath"/>
-
</groovyc>
-
</tasks>
-
</configuration>
-
<goals>
-
<goal>run</goal>
-
</goals>
-
</execution>
-
</executions>
-
</plugin>
This approach simply runs an ant task which executes the groovy compiler on all groovy files. For a simple project setup this approach works without problems but i run into some as I already have a maven-antrun-plugin in my parent pom.xml in the profile section. But profiles are not inherited to childs. This leads to some strange inheritance problems which i do not fully understand at the moment. Why they appear in the way the are appearing. As soon I've found a solution or at least found out the reason for the problems I run into I'll tell you. So stay tuned 
February 28th, 2007