- How do I disable Cobertura instrumentation on a project?
- I added a module to a parent pom.xml, and now the antrun plugin doesn’t work! What gives?
- How do I deploy a library to an Internal Repository?
- How do I get Maven to download the sources jar file for a given dependency?
- After I run eclipse:eclipse, I got a bunch of compiler errors in Eclipse. What do I do now?
There are instances where you may have multiple Maven projects, all inheriting from the same pom.xml. The case for us that brought this to our attention was having a separate allTests project, that contained integration tests. We wanted the project run as part of our build from the parent project, but there was no source code in the project. As a result, the Cobertura Maven Plugin barfs when it tries to instrument the project.
The problem is identified here: http://jira.codehaus.org/browse/MCOBERTURA-42
To fool the current version of the Cobertura Maven Plugin into not trying to instrument anything (and the nice side effect is that no coverage link is add when the site phase is run), we add the following:
<project> ... <build> ... <sourceDirectory>MCOBERTURA-42-HACK</sourceDirectory> ... </build> </project>
We had been using the Maven Antrun Plugin to generate the DDL for our project from Hibernate annotations using the HibernateTool. There is a parent pom.xml that specified the projects as modules, and we had added one more project. All of a sudden, our Maven build would fail with:
C:\eclipse\workspace\premisesRegistry\build.xml:9: taskdef class org.hibernate.tool.ant.HibernateToolTask cannot be found
but only when we ran the build from the parent. Building from the individual project worked fine. The module that was added was our modules for tests that had no src folder, which may or may not have made a difference.
We tracked it down to to order in which the modules are defined in the parent pom.xml. For whatever reason, if we defined the modules as:
<modules> <module>../alltests</module> <!-- new module with no src folder, tests only --> .... <module>../premisesRegistry</module> <!-- module using hibernateTool --> <module>../util</module> <module>../dataAnalyzer</module> </modules>
then we would get the above error. As soon as we switched it to:
<modules> .... <module>../premisesRegistry</module> <!-- module using hibernateTool --> <module>../util</module> <module>../dataAnalyzer</module> <module>../alltests</module> <!-- new module with no src folder, tests only --> </modules>
everything was great. I’d like to spend some more time to investigate why this is, but this just seems wonky.
MB – This is an old bug in the antrun plugin. http://jira.codehaus.org/browse/MNG-1323 The problem is that the first use of antrun sets the dependencies for all time. The hack/work-around is to put all ant dependencies you need on the first antrun occurrence in the build.
Occasionally, you may need to use a library in your project that does not exist on an external repository like Ibiblio. One workaround is to install the library in the internal release repository. You need to take the following steps to do so:
- Make sure that your Internal Repository is specified in your $MAVEN_HOME/conf/settings.xml file:
<server> <id>internalRepo</id> <username>username</username> <password>password</password> </server>
- In our case, we needed to use webdav as the protocol extension. So we had to run the mvn deploy command in a directory with a pom.xml file. The pom.xml file has wagon-webdav extension included. The wagon-webdav extensions allows the Maven client to communicate and create directories on the Internal repository:
<extensions> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-webdav</artifactId> <version>1.0-beta-2</version> </extension> </extensions>
- Next, run the mvn deploy command. For example, to deploy a jbpm file to our internal repository, we entered the following;
mvn deploy:deploy-file -DgroupId=jbpm -DartifactId=jbpm-jpdl -Dversion=3.2.2 -Dpackaging=jar \ -Dfile=path\to\our\jbpm-jpdl.jar -Durl=dav:http://mvnrepo.yourcompany.com/release -DrepositoryId=internalRepo
Example In this case, the -DrespositoryId value is left out and managed to commit the artifact to the repository. Is it optional?
mvn deploy:deploy-file -DgroupId=com.sdm.hw.hudson -DartifactId=slave -Dversion=1.278 -Dpackaging=jar -Dfile=slave.jar -Durl=dav:http://mvnrepo.intelliware.ca/release
Run the following command:
mvn -DdownloadSources=true eclipse:eclipse
This will download all dependencies and their sources to your local repository. Note that this will also update .classpath and .project.
Are you using multiple version of JDKs? If so, there is a good chance that the .classpath file generated by
eclipse:eclipse is not exactly what you wanted. One thing that I noticed,
eclipse:eclipse makes your project’s
JRE_CONTAINER points to your “Default JRE”. In which case, you must edit your Eclipse Build Path to have it point to the target JRE of your project.