RE: test failures
Hello, I am still blocked, does anyone have any more ideas on this? I am running with the latest version of maven 2.0.6. Thanks, -Moiz -Original Message- From: dohadwala, moiz Sent: Saturday, May 12, 2007 8:58 AM To: dohadwala, moiz; Maven Users List Subject: RE: test failures Sorry, that one got away: I tried setting that property: [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: D:\luntbuild\projects\has\has\common\target\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 9 seconds [INFO] Finished at: Sat May 12 08:55:57 PDT 2007 [INFO] Final Memory: 6M/11M [INFO] Thanks, -Moiz -Original Message- From: dohadwala, moiz Sent: Saturday, May 12, 2007 8:57 AM To: 'Maven Users List' Subject: RE: test failures Thanks for the response. I tried that, here's what I got: -Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Saturday, May 12, 2007 12:40 AM To: Maven Users List Subject: Re: test failures they are logged to a file, do mvn test -Dsurefire.useFile=false to log them to stdout - no need for -e or -X Andy On 12 May 2007, at 00:30, [EMAIL PROTECTED] wrote: > I am getting a test failure message from maven: > > [INFO] Trace > org.apache.maven.BuildFailureException: There are test failures. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals > (Default > LifecycleExecutor.java:560) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif > ec > ycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal > (DefaultL > ifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand > le > Failures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment > s( > DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute > (DefaultLifec > ycleExecutor.java:143) > at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: > 125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.jav > a:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessor > Impl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoFailureException: There are > test failures. > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute > (SurefirePlugin.j > ava:425 > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo > (DefaultPluginMa > nager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals > (Default > LifecycleExecutor.java:539) > ... 16 more > > This happens on teh build machine. It works fine on all the other > developer's machine. I have confirmed that the versions of maven, the > settings.xml are the same. This is with maven 2.0.6. > > Why won't maven print the real reason for the error? This stack trace > is useless. mvn -X doesn't provide any information that is useful > either. > > How do I debug this? > > -Moiz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: test failures
Sorry, that one got away: I tried setting that property: [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Nothing to compile - all classes are up to date [INFO] [surefire:test] [INFO] Surefire report directory: D:\luntbuild\projects\has\has\common\target\surefire-reports [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 9 seconds [INFO] Finished at: Sat May 12 08:55:57 PDT 2007 [INFO] Final Memory: 6M/11M [INFO] Thanks, -Moiz -Original Message- From: dohadwala, moiz Sent: Saturday, May 12, 2007 8:57 AM To: 'Maven Users List' Subject: RE: test failures Thanks for the response. I tried that, here's what I got: -Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Saturday, May 12, 2007 12:40 AM To: Maven Users List Subject: Re: test failures they are logged to a file, do mvn test -Dsurefire.useFile=false to log them to stdout - no need for -e or -X Andy On 12 May 2007, at 00:30, [EMAIL PROTECTED] wrote: > I am getting a test failure message from maven: > > [INFO] Trace > org.apache.maven.BuildFailureException: There are test failures. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals > (Default > LifecycleExecutor.java:560) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif > ec > ycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal > (DefaultL > ifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand > le > Failures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment > s( > DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute > (DefaultLifec > ycleExecutor.java:143) > at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: > 125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.jav > a:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessor > Impl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoFailureException: There are > test failures. > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute > (SurefirePlugin.j > ava:425 > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo > (DefaultPluginMa > nager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals > (Default > LifecycleExecutor.java:539) > ... 16 more > > This happens on teh build machine. It works fine on all the other > developer's machine. I have confirmed that the versions of maven, the > settings.xml are the same. This is with maven 2.0.6. > > Why won't maven print the real reason for the error? This stack trace > is useless. mvn -X doesn't provide any information that is useful > either. > > How do I debug this? > > -Moiz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: test failures
Thanks for the response. I tried that, here's what I got: -Original Message- From: Andrew Williams [mailto:[EMAIL PROTECTED] Sent: Saturday, May 12, 2007 12:40 AM To: Maven Users List Subject: Re: test failures they are logged to a file, do mvn test -Dsurefire.useFile=false to log them to stdout - no need for -e or -X Andy On 12 May 2007, at 00:30, [EMAIL PROTECTED] wrote: > I am getting a test failure message from maven: > > [INFO] Trace > org.apache.maven.BuildFailureException: There are test failures. > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals > (Default > LifecycleExecutor.java:560) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLif > ec > ycle(DefaultLifecycleExecutor.java:480) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal > (DefaultL > ifecycleExecutor.java:459) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHand > le > Failures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegment > s( > DefaultLifecycleExecutor.java:278) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute > (DefaultLifec > ycleExecutor.java:143) > at > org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java: > 125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke > (NativeMethodAccessorImpl.jav > a:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke > (DelegatingMethodAccessor > Impl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoFailureException: There are > test failures. > at > org.apache.maven.plugin.surefire.SurefirePlugin.execute > (SurefirePlugin.j > ava:425 > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo > (DefaultPluginMa > nager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals > (Default > LifecycleExecutor.java:539) > ... 16 more > > This happens on teh build machine. It works fine on all the other > developer's machine. I have confirmed that the versions of maven, the > settings.xml are the same. This is with maven 2.0.6. > > Why won't maven print the real reason for the error? This stack trace > is useless. mvn -X doesn't provide any information that is useful > either. > > How do I debug this? > > -Moiz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
test failures
I am getting a test failure message from maven: [INFO] Trace org.apache.maven.BuildFailureException: There are test failures. at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:560) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifec ycle(DefaultLifecycleExecutor.java:480) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultL ifecycleExecutor.java:459) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandle Failures(DefaultLifecycleExecutor.java:311) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments( DefaultLifecycleExecutor.java:278) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifec ycleExecutor.java:143) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) at org.apache.maven.cli.MavenCli.main(MavenCli.java:272) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav a:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor Impl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoFailureException: There are test failures. at org.apache.maven.plugin.surefire.SurefirePlugin.execute(SurefirePlugin.j ava:425 at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginMa nager.java:443) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Default LifecycleExecutor.java:539) ... 16 more This happens on teh build machine. It works fine on all the other developer's machine. I have confirmed that the versions of maven, the settings.xml are the same. This is with maven 2.0.6. Why won't maven print the real reason for the error? This stack trace is useless. mvn -X doesn't provide any information that is useful either. How do I debug this? -Moiz
"Unable to execute javadoc command" error
Hello, I am getting "Unable to execute javadoc command" errors while running mvn site on my project. I have maven 2.0.4 and javadoc plugin 2.1. The error happens in one of the modules only. The projects parent pom includes cobertura, surefire, and javadoc reporting. When I run maven with -Dmaven.test.skip=true mvn site runs fine without any javadoc error. I have run maven with -X and -e options to determine the cause of the exception. However, the stack trace isn't helpful. The root cause is an InterruptedException on the process input stream in plexus's command line util package. The svn source does not match the stacktrace line numbers anymore. I have manually run the javadoc tool on the module's source and it ran without errors, there were some warnings message. However, I don't believe they would cause the plugin error. How do I turn off the javadoc plugin for that module only, and still invoke it in the other modules. The project's parent pom is shared by other projects and I don't wish to disable javadoc for any other project. Thanks, -Moiz
Maven releases?
When is the next maven released scheduled? It is 7 months since the last maven 2 release. Thanks, -Moiz
RE: Consistency of deployed modules
Skipping tests before in the deploy makes me nervous. I have considered that too. You are right, snapshots only add up on the remote repository not the local one. So, at least disk space is not impacted. -Moiz -Original Message- From: Max Cooper [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 2:04 PM To: Maven Users List Subject: Re: Consistency of deployed modules To avoid running the tests twice, set maven.test.skip=true in the properties section of the 'mvn deploy' Builder. I am not sure if this would work, but to avoid the double-install, perhaps you could run 'mvn clean package' (instead of install) on the first phase. Are you sure running install twice uses more disk space than running it once? I am not using SNAPSHOTs, so installing mygroup:myartifact:1.0 twice doesn't take any more disk space than installing it once. -Max [EMAIL PROTECTED] wrote: > Thanks for response. > > That's similat what I have in place, and I am using luntbuild: > > mvn clean install > (on success: post build ) > mvn deploy site site:deply > > But the problem is that now I have to run unit tests multiple times. > My unit tests run for around 15 minutes. That brings the total build > time to 1 hour. This also doubles disk usage in the local repository > on the build machine because the install phase is invoked twice. > > There should be a more elegant way to do this than this ( IMO ) hack. > > > Thanks, > > -Moiz > > -Original Message- > From: Max Cooper [mailto:[EMAIL PROTECTED] > Sent: Tuesday, October 31, 2006 2:08 PM > To: Maven Users List > Subject: Re: Consistency of deployed modules > > Run maven twice: > >mvn clean install >if (success) mvn deploy > > Build server software like Luntbuild can automate this for you. > > -Max > > [EMAIL PROTECTED] wrote: >> I have a multi-project build. I run a "mvn clean deploy" build every >> night. Sometimes the builds fail with one of the modules and I end up >> with an inconsistent set of deployed modules. How can I delay the >> deployment of the modules so that the deploy happens only when all of >> the modules have sucessfully completed the install phase of the >> life-cycle. This way, I always have a consistent set of modules. >> >> Thanks >> >> -Moiz >> >> >> - >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Consistency of deployed modules
Thanks for response. That's similat what I have in place, and I am using luntbuild: mvn clean install (on success: post build ) mvn deploy site site:deply But the problem is that now I have to run unit tests multiple times. My unit tests run for around 15 minutes. That brings the total build time to 1 hour. This also doubles disk usage in the local repository on the build machine because the install phase is invoked twice. There should be a more elegant way to do this than this ( IMO ) hack. Thanks, -Moiz -Original Message- From: Max Cooper [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 31, 2006 2:08 PM To: Maven Users List Subject: Re: Consistency of deployed modules Run maven twice: mvn clean install if (success) mvn deploy Build server software like Luntbuild can automate this for you. -Max [EMAIL PROTECTED] wrote: > I have a multi-project build. I run a "mvn clean deploy" build every > night. Sometimes the builds fail with one of the modules and I end up > with an inconsistent set of deployed modules. How can I delay the > deployment of the modules so that the deploy happens only when all of > the modules have sucessfully completed the install phase of the > life-cycle. This way, I always have a consistent set of modules. > > Thanks > > -Moiz > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Consistency of deployed modules
I have a multi-project build. I run a "mvn clean deploy" build every night. Sometimes the builds fail with one of the modules and I end up with an inconsistent set of deployed modules. How can I delay the deployment of the modules so that the deploy happens only when all of the modules have sucessfully completed the install phase of the life-cycle. This way, I always have a consistent set of modules. Thanks -Moiz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Site plugin and modules
I have a multi-module project. The modules POMs are inheriting from a super-POM ( which is different from the aggregator POM ). When I run the site plugin, the sites for aggregator POM does not list the modules under the Modules section. If I change the module POMs to inherit from the project POM, the modules show up. Also, when the module POMs inherit from the super-POM, the module site is deployed under the parent site and not the aggregator project site. So, how do I get the modules to be deployed correctly, is there anything in the project POM that needs to be configured differently? Or, is this a practice that is frowned on? +-Parent +-pom.xml +-project +- module 1 +-pom.xml ( derives from parent\pom.xml ) +- module 2 +-pom.xml ( derives from parent\pom.xml ) +- pom.xml( the aggregator pom ) -Moiz
Compile error looking for SiteRenderer.java
I had a report plugin that used to compile with maven-reporting-impl-2.0.1. When I switched to using maven 2.0.2. I tried to switch to using maven-reporting-impl-2.0.2. However, now I get unresolved symbol errors for SiteRenderer.java. It is no longer in doxia-core version 1-alpha-7. Is there a migration path from 2.0.1 to 2.0.2 for report plugins? -Moiz
