How can I get missing methods in sonar that I don't get in the regular maven build?

View: New views
6 Messages — Rating Filter:   Alert me  

How can I get missing methods in sonar that I don't get in the regular maven build?

by bimargulies :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I've set my standard hudson job for my project to run Sonar every time.

The main maven build ran clean. No errors.

The subsequent sonar processing got failures from undefined methods:
as if the sonar run of surefire somehow ended up with a mixture of old
and new code.

I don't know where to start diagnosing this. Help?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Re: How can I get missing methods in sonar that I don't get in the regular maven build?

by Freddy Mallet :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Benson,

In any case, your sources need to be compile, it's why we recommend [1] to launch 

mvn clean install -Dtest=false -DfailIfNoTests=false

and then 

mvn sonar:sonar

Could you configure your hudson job to do first this compilation ? If you still have an error, please send your log file.

Freddy

[1] - http://docs.codehaus.org/display/SONAR/Collect+data

On Mon, Jun 22, 2009 at 5:15 PM, Benson Margulies <bimargulies@...> wrote:
I've set my standard hudson job for my project to run Sonar every time.

The main maven build ran clean. No errors.

The subsequent sonar processing got failures from undefined methods:
as if the sonar run of surefire somehow ended up with a mixture of old
and new code.

I don't know where to start diagnosing this. Help?

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




Re: How can I get missing methods in sonar that I don't get in the regular maven build?

by bimargulies :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

The differences between what I have and what you recommend are:

a) I don't have 'clean'
b) I don't have the -D's. So, I'm first running the regular mvn
install and unit tests, and all is well, and then I ran sonar and
things failed.

I don't know if I can reproduce this.

I'm inclined to start by adding 'clean'.


On Mon, Jun 22, 2009 at 3:53 PM, Freddy Mallet<freddy.mallet@...> wrote:

> Hi Benson,
> In any case, your sources need to be compile, it's why we recommend [1] to
> launch
> mvn clean install -Dtest=false -DfailIfNoTests=false
> and then
> mvn sonar:sonar
> Could you configure your hudson job to do first this compilation ? If you
> still have an error, please send your log file.
> Freddy
> [1] - http://docs.codehaus.org/display/SONAR/Collect+data
>
> On Mon, Jun 22, 2009 at 5:15 PM, Benson Margulies <bimargulies@...>
> wrote:
>>
>> I've set my standard hudson job for my project to run Sonar every time.
>>
>> The main maven build ran clean. No errors.
>>
>> The subsequent sonar processing got failures from undefined methods:
>> as if the sonar run of surefire somehow ended up with a mixture of old
>> and new code.
>>
>> I don't know where to start diagnosing this. Help?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Re: How can I get missing methods in sonar that I don't get in the regular maven build?

by bimargulies :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Here's the backtrace. My hudson config looks now exactly like yours.
The missing method is defined, and all is well when I run sonar:sonar
from my personal machine.

com.basistech.util.LanguageCode.ISO639_1()Ljava/lang/String;
java.lang.NoSuchMethodError:
com.basistech.util.LanguageCode.ISO639_1()Ljava/lang/String;
at com.basistech.rlp.BaseLinguisticsTokenFilterFactory.getTokenFilter(BaseLinguisticsTokenFilterFactory.java:141)
at com.basistech.rlp.BaseLinguisticsTokenFilter.(BaseLinguisticsTokenFilter.java:90)
at com.basistech.rlp.TestWrapperFilter.testFilter(TestWrapperFilter.java:57)
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.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
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:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)

On Mon, Jun 22, 2009 at 5:42 PM, Benson Margulies<bimargulies@...> wrote:

> The differences between what I have and what you recommend are:
>
> a) I don't have 'clean'
> b) I don't have the -D's. So, I'm first running the regular mvn
> install and unit tests, and all is well, and then I ran sonar and
> things failed.
>
> I don't know if I can reproduce this.
>
> I'm inclined to start by adding 'clean'.
>
>
> On Mon, Jun 22, 2009 at 3:53 PM, Freddy Mallet<freddy.mallet@...> wrote:
>> Hi Benson,
>> In any case, your sources need to be compile, it's why we recommend [1] to
>> launch
>> mvn clean install -Dtest=false -DfailIfNoTests=false
>> and then
>> mvn sonar:sonar
>> Could you configure your hudson job to do first this compilation ? If you
>> still have an error, please send your log file.
>> Freddy
>> [1] - http://docs.codehaus.org/display/SONAR/Collect+data
>>
>> On Mon, Jun 22, 2009 at 5:15 PM, Benson Margulies <bimargulies@...>
>> wrote:
>>>
>>> I've set my standard hudson job for my project to run Sonar every time.
>>>
>>> The main maven build ran clean. No errors.
>>>
>>> The subsequent sonar processing got failures from undefined methods:
>>> as if the sonar run of surefire somehow ended up with a mixture of old
>>> and new code.
>>>
>>> I don't know where to start diagnosing this. Help?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Re: How can I get missing methods in sonar that I don't get in the regular maven build?

by Olivier Gaudin-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello Benson,

Could you give it a try by using a freestyle job in Hudson instead of a Maven job ?

Olivier


On Tue, Jun 23, 2009 at 1:44 AM, Benson Margulies <bimargulies@...> wrote:
Here's the backtrace. My hudson config looks now exactly like yours.
The missing method is defined, and all is well when I run sonar:sonar
from my personal machine.

com.basistech.util.LanguageCode.ISO639_1()Ljava/lang/String;
java.lang.NoSuchMethodError:
com.basistech.util.LanguageCode.ISO639_1()Ljava/lang/String;
at com.basistech.rlp.BaseLinguisticsTokenFilterFactory.getTokenFilter(BaseLinguisticsTokenFilterFactory.java:141)
at com.basistech.rlp.BaseLinguisticsTokenFilter.(BaseLinguisticsTokenFilter.java:90)
at com.basistech.rlp.TestWrapperFilter.testFilter(TestWrapperFilter.java:57)
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.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
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:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)

On Mon, Jun 22, 2009 at 5:42 PM, Benson Margulies<bimargulies@...> wrote:
> The differences between what I have and what you recommend are:
>
> a) I don't have 'clean'
> b) I don't have the -D's. So, I'm first running the regular mvn
> install and unit tests, and all is well, and then I ran sonar and
> things failed.
>
> I don't know if I can reproduce this.
>
> I'm inclined to start by adding 'clean'.
>
>
> On Mon, Jun 22, 2009 at 3:53 PM, Freddy Mallet<freddy.mallet@...> wrote:
>> Hi Benson,
>> In any case, your sources need to be compile, it's why we recommend [1] to
>> launch
>> mvn clean install -Dtest=false -DfailIfNoTests=false
>> and then
>> mvn sonar:sonar
>> Could you configure your hudson job to do first this compilation ? If you
>> still have an error, please send your log file.
>> Freddy
>> [1] - http://docs.codehaus.org/display/SONAR/Collect+data
>>
>> On Mon, Jun 22, 2009 at 5:15 PM, Benson Margulies <bimargulies@...>
>> wrote:
>>>
>>> I've set my standard hudson job for my project to run Sonar every time.
>>>
>>> The main maven build ran clean. No errors.
>>>
>>> The subsequent sonar processing got failures from undefined methods:
>>> as if the sonar run of surefire somehow ended up with a mixture of old
>>> and new code.
>>>
>>> I don't know where to start diagnosing this. Help?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email




Re: How can I get missing methods in sonar that I don't get in the regular maven build?

by bimargulies :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello Olivier,

I could, but I have a confession to make. As I was anxious to make progress, I completely deleted my project and tried again. The problem discussed here disappeared. It was replaced with the situation I reported with classes reporting 0% unit test success while passing all their unit tests. And now that problem has also gone away.

The next time something strange happens I'll try this.

--benson


On Tue, Jun 23, 2009 at 5:22 AM, Olivier Gaudin <gaudol@...> wrote:
Hello Benson,

Could you give it a try by using a freestyle job in Hudson instead of a Maven job ?

Olivier


On Tue, Jun 23, 2009 at 1:44 AM, Benson Margulies <bimargulies@...> wrote:
Here's the backtrace. My hudson config looks now exactly like yours.
The missing method is defined, and all is well when I run sonar:sonar
from my personal machine.

com.basistech.util.LanguageCode.ISO639_1()Ljava/lang/String;
java.lang.NoSuchMethodError:
com.basistech.util.LanguageCode.ISO639_1()Ljava/lang/String;
at com.basistech.rlp.BaseLinguisticsTokenFilterFactory.getTokenFilter(BaseLinguisticsTokenFilterFactory.java:141)
at com.basistech.rlp.BaseLinguisticsTokenFilter.(BaseLinguisticsTokenFilter.java:90)
at com.basistech.rlp.TestWrapperFilter.testFilter(TestWrapperFilter.java:57)
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.junit.internal.runners.TestMethod.invoke(TestMethod.java:59)
at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98)
at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79)
at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87)
at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77)
at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42)
at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88)
at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51)
at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44)
at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27)
at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37)
at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42)
at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140)
at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127)
at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
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:345)
at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)

On Mon, Jun 22, 2009 at 5:42 PM, Benson Margulies<bimargulies@...> wrote:
> The differences between what I have and what you recommend are:
>
> a) I don't have 'clean'
> b) I don't have the -D's. So, I'm first running the regular mvn
> install and unit tests, and all is well, and then I ran sonar and
> things failed.
>
> I don't know if I can reproduce this.
>
> I'm inclined to start by adding 'clean'.
>
>
> On Mon, Jun 22, 2009 at 3:53 PM, Freddy Mallet<freddy.mallet@...> wrote:
>> Hi Benson,
>> In any case, your sources need to be compile, it's why we recommend [1] to
>> launch
>> mvn clean install -Dtest=false -DfailIfNoTests=false
>> and then
>> mvn sonar:sonar
>> Could you configure your hudson job to do first this compilation ? If you
>> still have an error, please send your log file.
>> Freddy
>> [1] - http://docs.codehaus.org/display/SONAR/Collect+data
>>
>> On Mon, Jun 22, 2009 at 5:15 PM, Benson Margulies <bimargulies@...>
>> wrote:
>>>
>>> I've set my standard hudson job for my project to run Sonar every time.
>>>
>>> The main maven build ran clean. No errors.
>>>
>>> The subsequent sonar processing got failures from undefined methods:
>>> as if the sonar run of surefire somehow ended up with a mixture of old
>>> and new code.
>>>
>>> I don't know where to start diagnosing this. Help?
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>    http://xircles.codehaus.org/manage_email
>>>
>>>
>>
>>
>

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

   http://xircles.codehaus.org/manage_email