6 Replies Latest reply on Aug 31, 2007 1:59 PM by pgier

    mvn vs eclipse test runs

    starksm64

      When I build the mc modules I see many errors in the kernel module:

      Tests run: 760, Failures: 0, Errors: 405, Skipped: 0

      Running the same tests from eclipse I see no errors, and more tests:
      Tests run: 820, Failures: 0, Errors: 0, Skipped: 0

      The cruisecontrol runs don't show this discrepancy. How are they running the tests?

      I would like to update the deployer/managed/metatype snapshot jars so I can synch up my changes in the jboss5 trunk.

        • 1. Re: mvn vs eclipse test runs

          When I run from the command line, I get:

          Results :
          
          Tests run: 823, Failures: 0, Errors: 0, Skipped: 0
          


          • 2. Re: mvn vs eclipse test runs
            alesj

             

            "scott.stark@jboss.org" wrote:
            How are they running the tests?


            I'm running them from command line, and I get the same thing Adrian gets.
            I'm also using IDEA Maven2 plugin, which is basically the same as command line - except the output is in the IDEA console.

            I also installed TeamCity build server from IntalliJ, which has an interesting feature - when you want to commit, it gives you an option to build/test it before by delegating to TeamCity, and if tests are OK, only then it pushes the commit.
            Which is really great, but this means all our test must work before your commit try. :-)

            • 3. Re: mvn vs eclipse test runs
              starksm64

              If I run mvn test I see the same errors as when I ran the install:

              Tests run: 760, Failures: 0, Errors: 405, Skipped: 0
              
              [ERROR] There are test failures.
              [INFO] ------------------------------------------------------------------------
              [INFO] BUILD SUCCESSFUL
              [INFO] ------------------------------------------------------------------------
              [INFO] Total time: 14 seconds
              [INFO] Finished at: Fri Aug 31 07:58:35 PDT 2007
              [INFO] Final Memory: 18M/294M
              [INFO] ------------------------------------------------------------------------
              [starksm@succubus kernel]$
              


              I guess something is out of synch in my local mvn repo that does not affect eclipse? I'll try to track it down so I can update the jboss5 mc snapshot libs.


              • 4. Re: mvn vs eclipse test runs
                starksm64

                Looking at one test failure, the problem seems to be that the dependency module is not up to date:

                <testcase time="0.004" name="testValueFactory">
                ?
                 <error type="java.lang.AbstractMethodError" message="org.jboss.dependency.plugins.AbstractDependencyInfo.setAutowireCandidate(Z)V">
                java.lang.AbstractMethodError: org.jboss.dependency.plugins.AbstractDependencyInfo.setAutowireCandidate(Z)V
                 at org.jboss.kernel.plugins.dependency.AbstractKernelControllerContext.&init&(AbstractKernelControllerContext.java:87)
                 at org.jboss.kernel.plugins.dependency.AbstractKernelController.install(AbstractKernelController.java:94)
                 at org.jboss.kernel.plugins.dependency.AbstractKernelController.install(AbstractKernelController.java:89)
                 at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.instantiate(AbstractKernelConfigTest.java:114)
                 at org.jboss.test.kernel.config.test.AbstractKernelConfigTest.instantiate(AbstractKernelConfigTest.java:108)
                 at org.jboss.test.kernel.config.test.ValueFactoryTestCase.instantiateHolder(ValueFactoryTestCase.java:89)
                 at org.jboss.test.kernel.config.test.ValueFactoryTestCase.testValueFactory(ValueFactoryTestCase.java:70)
                 at org.jboss.test.kernel.config.test.ValueFactoryTestCase.testValueFactory(ValueFactoryTestCase.java:70)
                 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                 at java.lang.reflect.Method.invoke(Method.java:585)
                 at junit.framework.TestCase.runTest(TestCase.java:154)
                 at junit.framework.TestCase.runBare(TestCase.java:127)
                 at junit.framework.TestResult$1.protect(TestResult.java:106)
                 at junit.framework.TestResult.runProtected(TestResult.java:124)
                 at junit.framework.TestResult.run(TestResult.java:109)
                 at junit.framework.TestCase.run(TestCase.java:118)
                 at junit.framework.TestSuite.runTest(TestSuite.java:208)
                 at junit.framework.TestSuite.run(TestSuite.java:203)
                 at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
                 at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
                 at junit.framework.TestResult.runProtected(TestResult.java:124)
                 at junit.extensions.TestSetup.run(TestSetup.java:23)
                 at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
                 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                 at java.lang.reflect.Method.invoke(Method.java:585)
                 at org.apache.maven.surefire.junit.JUnitTestSet.execute(JUnitTestSet.java:213)
                 at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:138)
                 at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:125)
                 at org.apache.maven.surefire.Surefire.run(Surefire.java:132)
                 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
                 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
                 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
                 at java.lang.reflect.Method.invoke(Method.java:585)
                 at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:290)
                 at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:818)
                </error>
                




                [DEBUG] jboss-dependency: using locally installed snapshot
                [DEBUG] Retrieving parent-POM: org.jboss.microcontainer:jboss-microcontainer::2.0.0-SNAPSHOT for project: null:jboss-dependency:jar:2.0.0-SNAPSHOT from the repository.


                and it looks like this could be out of date:

                [starksm@succubus bin]$ ls -lt /home/svn/repository.jboss.com/maven2/org/jboss/microcontainer/jboss-dependency/2.0.0-SNAPSHOT/
                total 380
                -rw-rw-r-- 1 starksm starksm 374 Aug 31 09:05 maven-metadata-jboss-snapshots.xml
                -rw-rw-r-- 1 starksm starksm 374 Aug 31 09:05 maven-metadata-snapshots.jboss.org.xml
                -rw-rw-r-- 1 starksm starksm 40 Aug 31 07:58 maven-metadata-jboss-snapshots.xml.sha1
                -rw-rw-r-- 1 starksm starksm 40 Aug 31 07:58 maven-metadata-snapshots.jboss.org.xml.sha1
                -rw-rw-r-- 1 starksm starksm 57104 Aug 30 23:50 jboss-dependency-2.0.0-SNAPSHOT.jar
                -rw-rw-r-- 1 starksm starksm 57017 Aug 30 23:50 jboss-dependency-2.0.0-SNAPSHOT-plugins.jar
                -rw-rw-r-- 1 starksm starksm 2316 Aug 30 23:50 jboss-dependency-2.0.0-SNAPSHOT.pom
                -rw-rw-r-- 1 starksm starksm 56237 Aug 30 23:50 jboss-dependency-2.0.0-SNAPSHOT-sources.jar
                -rw-rw-r-- 1 starksm starksm 15476 Aug 30 23:50 jboss-dependency-2.0.0-SNAPSHOT-spi.jar
                -rw-rw-r-- 1 starksm starksm 328 Aug 30 23:50 maven-metadata-local.xml
                -rw-rw-r-- 1 starksm starksm 52054 Aug 28 20:16 jboss-dependency-2.0.0-20070809.154918-6.jar
                -rw-rw-r-- 1 starksm starksm 40 Aug 28 20:16 jboss-dependency-2.0.0-20070809.154918-6.jar.sha1
                -rw-rw-r-- 1 starksm starksm 47496 Jul 28 13:45 jboss-dependency-2.0.0-SNAPSHOT-jdk14.jar


                After doing a clean/install of the dependency project, I see a different result for the kernel:

                Tests run: 805, Failures: 240, Errors: 135, Skipped: 0


                so it looks like the mc modules are not being properly rebuilt.


                • 5. Re: mvn vs eclipse test runs
                  starksm64

                  So after doing a mvn clean/install from the mc root, all is well:


                  [starksm@succubus kernel]$ mvn test
                  [INFO] Scanning for projects...
                  [INFO] ----------------------------------------------------------------------------
                  [INFO] Building JBoss Microcontainer Kernel
                  [INFO] task-segment: [test]
                  ...
                  Tests run: 823, Failures: 0, Errors: 0, Skipped: 0


                  so apparently mvn is not tracking the state of the mc projects correctly?


                  • 6. Re: mvn vs eclipse test runs
                    pgier

                    With cruise control and hudson, the whole mc project gets built, so that later modules can depend on the artifacts from earlier modules. I think what happened for you is that your local repo artifacts were out of date, but still newer than the ones on the snapshot server (snapshots.jboss.org), so maven decided to use your local one.

                    I can change the hudson build so that it deploys the artifacts to the snapshot server at the end of a build. That way the dependencies would only be 1 day out of date.