From Fedora Project Wiki

Line 73: Line 73:
'''-Dmaven.test.skip=true'''
'''-Dmaven.test.skip=true'''


== Misc ==
== Examples ==
=== javadoc:javadoc issue ===
=== javadoc:javadoc issue ===


Line 91: Line 91:


Solution is pretty simple: use '''javadoc:aggregate''' instead. Another advantage of this approach is that you will not have to merge javadocs for all modules manually. Merged javadoc will be created in <code>target/site/apidocs</code> in top-level project
Solution is pretty simple: use '''javadoc:aggregate''' instead. Another advantage of this approach is that you will not have to merge javadocs for all modules manually. Merged javadoc will be created in <code>target/site/apidocs</code> in top-level project
=== CommandLineException: Error inside systemErr parser ===
This error shows up during test phase and looks something like this:
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error while executing forked tests.; nested exception is org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser
[INFO] ------------------------------------------------------------------------
[INFO] For more information, run Maven with the -e switch
This issue is caused by updated maven-surefire. See [http://jira.codehaus.org/browse/SUREFIRE-640] for details. Until the bug is fixed you can call mvn-jpp with '''-Dmaven.test.redirectTestOutputToFile=false'''

Revision as of 15:10, 1 September 2010

Packaging Maven in Fedora can be quite frustrating experience, especially in the beginning. I'll try to collect common error messages and fixes that will show you how to workaround these problems

Basic issues with dependencies

Compilation failures

Test failures

Test WILL fail sooner or later for some of your packages. There are several ways to fix or workaround them and I ordered them from best to worst:

Fixing those tests properly

Best way to solve failing tests is to fix them so that they will work OK. This is not always possible, sometimes running tests require network access (not available on koji) or are too resource-hungry to successfully run there. How do these failing tests show up? For example like this:

[ERROR] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Compilation failure
/builddir/build/BUILD/modello-1.4/modello-plugins/modello-plugin-xml/src/test/java/org/codehaus/modello/plugins/xml/XmlModelloPluginTest.java:[58,44] container has private access in org.codehaus.plexus.PlexusTestCase
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.BuildFailureException: Compilation failure
/builddir/build/BUILD/modello-1.4/modello-plugins/modello-plugin-xml/src/test/java/org/codehaus/modello/plugins/xml/XmlModelloPluginTest.java:[58,44] container has private access in org.codehaus.plexus.PlexusTestCase                                                 
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:715)     
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)        
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)

This is typical compilation failure caused by different version of dependency that we provide vs. what package expects. In this case we can inspect XmlModelloPluginTest.java and on line 58 we'll find:

ModelloCore modello = (ModelloCore) container.lookup( ModelloCore.ROLE );

container variable was inherited from PlexusTestCase. Older versions of PlexusTestCase class within plexus-default-container had this variable as protected (plus public getContainer() function). Newer versions of PlexusTestCase changed container variable permissions to private and offer only public getContainer() function. Most test compilation failures I have encountered were caused by changes in API and these should generally be relatively easy to fix.

Therefore simple solution for this is this patch:

+diff --git a/modello-plugins/modello-plugin-xml/src/test/java/org/codehaus/modello/plugins/xml/XmlModelloPluginTest.java b/modello-plugins
+index d9a2113..ab737bc 100644
+--- a/modello-plugins/modello-plugin-xml/src/test/java/org/codehaus/modello/plugins/xml/XmlModelloPluginTest.java
++++ b/modello-plugins/modello-plugin-xml/src/test/java/org/codehaus/modello/plugins/xml/XmlModelloPluginTest.java
+@@ -55,7 +55,7 @@ public class XmlModelloPluginTest
+     public void testXmlPlugin()
+         throws Exception
+     {
+-        ModelloCore modello = (ModelloCore) container.lookup( ModelloCore.ROLE );
++        ModelloCore modello = (ModelloCore) getContainer().lookup( ModelloCore.ROLE );
+ 
+         Model model = modello.loadModel( getTestFile( "src/test/resources/model.mdo" ) );
+ 

After updating package to newer dependency it might be a good idea to contact upstream and work with them on updating their dependency too.

Removing tests expected to fail

As mentioned in the previous section, sometimes tests need Internet access or a lot of resources. When it's not possible to modify tests and these are known to fail because of koji specifics, you can remove some of them specifically to enable rest of tests to work.

Ignoring failures

Sometimes tests compile OK but fail during runtime. Maybe there are genuine problems with the package and test failures should be inspected so that these problems will not affect users/developers. Usually it's best to test this failing package at least with some other package depending on it so that some of functionality is tested.

You can ignore test failures using: -Dmaven.test.failure.ignore=true

Using this should be accompanied with a comment why are the test failures ignored, if there are tests expected to fail, etc.

Skipping tests entirely

This solution should be used as a last resort and always accompanied with a comment explaining at least basic reasoning why tests were skipped and what other solutions were tried. This is needed mostly when some of required packages are too old. You should file a bug to update the out-of-date package. Perhaps include a comment like: "# skip tests because we have too old xmlunit in Fedora now (1.0.8). See update bug #xxxxx"

To skip tests you can use: -Dmaven.test.skip=true

Examples

javadoc:javadoc issue

You can encounter this bug when trying to create javadocs for multi-module maven projects:

[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.7:javadoc': Unable to load the mojo 'org.apache.maven.plugins:maven-javadoc-plugin:2.7:javadoc' in the plugin 'org.apache.maven.plugins:maven-javadoc-plugin'. A required class is missing: org/apache/maven/shared/invoker/MavenInvocationException
org.apache.maven.shared.invoker.MavenInvocationException
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'org.apache.maven.plugins:maven-javadoc-plugin:2.7:javadoc': Unable to load the mojo 'org.apache.maven.plugins:maven-javadoc-plugin:2.7:javadoc' in the plugin 'org.apache.maven.plugins:maven-javadoc-plugin'. A required class is missing: org/apache/maven/shared/invoker/MavenInvocationException
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:698)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:569)
	at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:539)

Solution is pretty simple: use javadoc:aggregate instead. Another advantage of this approach is that you will not have to merge javadocs for all modules manually. Merged javadoc will be created in target/site/apidocs in top-level project

CommandLineException: Error inside systemErr parser

This error shows up during test phase and looks something like this:

[INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Error while executing forked tests.; nested exception is org.apache.maven.surefire.booter.shade.org.codehaus.plexus.util.cli.CommandLineException: Error inside systemErr parser [INFO] ------------------------------------------------------------------------ [INFO] For more information, run Maven with the -e switch

This issue is caused by updated maven-surefire. See [1] for details. Until the bug is fixed you can call mvn-jpp with -Dmaven.test.redirectTestOutputToFile=false