atom feed9 messages in org.codehaus.sonar.userRe: [sonar-user] IBM JDK 1.5 - UFT8 b...
FromSent OnAttachments
Martin RöbertJan 26, 2012 1:44 am 
Evgeny MandrikovJan 26, 2012 2:24 am 
Martin RöbertJan 26, 2012 2:33 am 
Evgeny MandrikovJan 26, 2012 2:43 am 
Martin RöbertJan 26, 2012 3:51 am.log
Evgeny MandrikovJan 26, 2012 4:03 am 
Martin RöbertJan 26, 2012 4:08
Evgeny MandrikovJan 26, 2012 4:27 am 
Martin RöbertJan 26, 2012 5:07 am 
Subject:Re: [sonar-user] IBM JDK 1.5 - UFT8 bug - Suppressing affected test classes from sonar analysis
From:Evgeny Mandrikov (
Date:Jan 26, 2012 4:27:50 am

Oh, sorry - in fact I've missed root cause, which has nothing with encoding :

Caused by: org.sonar.api.resources.DuplicatedSourceException: org.testng.eclipse.ui.util.StringUtilsTest

And also :

[INFO] [12:46:57.066] Source directories: [INFO] [12:46:57.066] /data/jenkins/workspace/ProBaTe.web/eclipse/de.lpzebusiness.testng/src/main [INFO] [12:46:57.066] /data/jenkins/workspace/ProBaTe.web/eclipse/de.lpzebusiness.testng/src/test/java [INFO] [12:46:57.067] Test directories: [INFO] [12:46:57.067] /data/jenkins/workspace/ProBaTe.web/eclipse/de.lpzebusiness.testng/src/test/java

So directory "src/test/java" specified two times - one time as source directory and another time as test directory. I suppose that this is due to Maven Tycho and solution was already proposed - Hope this will help.

On Thu, Jan 26, 2012 at 16:08, Martin Röbert <>wrote:

As I said i tried it in UTF-8 and US-ASCII - with the same result. ATM I use US-ASCII.

Find the Java file attached.

Cheers, Martin

Am 26.01.2012 um 13:03 schrieb Evgeny Mandrikov:

As I can see from your log : org.sonar.api.utils.SonarException: Unable to read and import the source

file : '/data/jenkins/workspace/ProBaTe.web/eclipse/de.lpzebusiness.testng/src/test/java/org/testng/eclipse/ui/util/' with the charset : 'US-ASCII'.

This means that Sonar tries to read files as "US-ASCII". So why we talk about UTF-8 ? If files are in UTF-8, then I guess that property

"" not specified in pom.xml or specified incorrectly.

If files are really in US-ASCII, then could you please provide ?

On Thu, Jan 26, 2012 at 15:51, Martin Röbert <> wrote: Maybe I missed something in the whole IBM VM discussion ;)

I'll provide a log file.

Thanks in advance Martin

Am 26.01.2012 um 11:43 schrieb Evgeny Mandrikov:

In this case you can't say that you have same problem as was described by Mike. And I believe that in this case you should provide more details - at least full log of build with failure.

On Thu, Jan 26, 2012 at 14:33, Martin Röbert <> wrote: Hi,

You mean like every single source file in all my project have non UTF-8 or non US-ASCII in it?

Maven and Jenkins are fine and compile everything only Sonar has problems with that?

Am 26.01.2012 um 11:24 schrieb Evgeny Mandrikov:


As was said before - root cause is that file(s) contain non UTF-8 characters. And best solution is to fix files.

On Thu, Jan 26, 2012 at 13:44, Martin Röbert <> wrote: Hi there,

I have the same problem as described by Mike but with the Oracle VM. Tried it with UTF-8 and US-ASCII encoding.

I read through the messages and checked all questions: - Happens with all source files - exclusions have no effect. - It is not a cobertura problem

Any hints on that?

Cheers, Martin


Our Sonar analysis fails with the following type errors:

[ERROR] Failed to execute goal org.codehaus.mojo:sonar-maven-plugin:2.0:sonar (default-cli) on project search-content: Can not execute Sonar: Unable to read and import the source file :


with the charset : ' UTF-8 <

MalformedInputException -> [Help 1]

We have to use the IBM 1.5 JDK for our build and we have tracked the above error down to a bug with this JDK, see; . We have proved it is this bug by using the Sun/Oracle 1.6 JDK, which if used resolves these errors. Using the work around in the IBM article places us in a catch 22 siutauion as one of our other classes fails with a code page error.

The test classes run with out issue in Coberture (run as part of a jenkins/maven job) and it is only when the classes are analysed with sonar that this error is generated even though sonar is not running Unit test analysis. So it appears that they are being accessed to perform additional profiling. As we have to use IBM 1.5 JDK currently we/I have tried exclude the test classes using the the "sonar.exclusions" key word at the command line in pom.xml and via the sonar UI, but the above error is still generated. The value I am using for the exclusion is:


We don't want to get rid of the tests as they are valid and when we eventually do upgrade they will work, so any help in getting them excluded as an interim measure would be handy