SonarQube
  1. SonarQube
  2. SONAR-222

StackOverflowError exception when extensions are defined in the pom

    Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.2, 1.2.1
    • Fix Version/s: 1.8
    • Component/s: Maven Plugin
    • Labels:
      None
    • Number of attachments :
      0

      Description

      Arnaud Heritier notices (http://www.mail-archive.com/dev@maven.apache.org/msg73926.html) :

      I have an infinite loop with the sonar plugin :
      09-Apr-2008 03:23:10    [ERROR] Cannot execute the command
      org.codehaus.sonar:sonar-core-maven-plugin:1.2:prepare
      09-Apr-2008 03:23:10    java.lang.StackOverflowError
      09-Apr-2008 03:23:10            at
      java.security.AccessController.doPrivileged(Native Method)
      09-Apr-2008 03:23:10            at
      java.net.URLClassLoader.findResource(URLClassLoader.java:359)
      09-Apr-2008 03:23:10            at
      org.codehaus.classworlds.RealmClassLoader.findResource(RealmClassLoader.java:232)
      09-Apr-2008 03:23:10            at
      java.lang.ClassLoader.getResource(ClassLoader.java:977)
      09-Apr-2008 03:23:10            at
      org.codehaus.classworlds.RealmClassLoader.getResourceDirect(RealmClassLoader.java:247)
      09-Apr-2008 03:23:10            at
      org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:300)
      09-Apr-2008 03:23:10            at
      org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237)
      09-Apr-2008 03:23:10            at
      org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288)
      09-Apr-2008 03:23:10            at
      org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314)
      09-Apr-2008 03:23:10            at
      org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237)
      09-Apr-2008 03:23:10            at
      org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288)
      09-Apr-2008 03:23:10            at
      org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314)
      

        Issue Links

          Activity

          Hide
          Jean-Paul GUIGUI added a comment -

          Same kind of issue with maven 2.0.9 and sonar 1.2.1 with JDK 1.6.0_04 in the prepare target of sonar, but with a stack slightly different:
          Failing for both single module and mutli-modules projects.
          Failing as well for simple project without dependency.

          Command line use: mvn org.codehaus.sonar:sonar-maven-plugin:1.2.1:sonar 2.1:sonar

          [ERROR] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.2.1:prepare
          java.lang.StackOverflowError
          at java.util.zip.ZipFile.getEntry(ZipFile.java:148)
          at java.util.jar.JarFile.getEntry(JarFile.java:206)
          at java.util.jar.JarFile.getJarEntry(JarFile.java:189)
          at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:754)
          at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:732)
          at sun.misc.URLClassPath.findResource(URLClassPath.java:145)
          at java.net.URLClassLoader$2.run(URLClassLoader.java:362)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findResource(URLClassLoader.java:359)
          at org.codehaus.classworlds.RealmClassLoader.findResource(RealmClassLoader.java:232)
          at java.lang.ClassLoader.getResource(ClassLoader.java:977)
          at org.codehaus.classworlds.RealmClassLoader.getResourceDirect(RealmClassLoader.java:247)
          at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:300)
          at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237)
          at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288)
          at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314)
          at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237)
          at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288)
          at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288)
          at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314)
          ..........
          ..........
          [INFO] ------------------------------------------------------------------------
          [ERROR] BUILD ERROR
          [INFO] ------------------------------------------------------------------------
          [INFO] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.2.1:prepare

          Show
          Jean-Paul GUIGUI added a comment - Same kind of issue with maven 2.0.9 and sonar 1.2.1 with JDK 1.6.0_04 in the prepare target of sonar, but with a stack slightly different: Failing for both single module and mutli-modules projects. Failing as well for simple project without dependency. Command line use: mvn org.codehaus.sonar:sonar-maven-plugin:1.2.1:sonar 2.1:sonar [ERROR] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.2.1:prepare java.lang.StackOverflowError at java.util.zip.ZipFile.getEntry(ZipFile.java:148) at java.util.jar.JarFile.getEntry(JarFile.java:206) at java.util.jar.JarFile.getJarEntry(JarFile.java:189) at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:754) at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:732) at sun.misc.URLClassPath.findResource(URLClassPath.java:145) at java.net.URLClassLoader$2.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(URLClassLoader.java:359) at org.codehaus.classworlds.RealmClassLoader.findResource(RealmClassLoader.java:232) at java.lang.ClassLoader.getResource(ClassLoader.java:977) at org.codehaus.classworlds.RealmClassLoader.getResourceDirect(RealmClassLoader.java:247) at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:300) at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237) at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288) at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314) at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237) at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288) at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288) at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314) .......... .......... [INFO] ------------------------------------------------------------------------ [ERROR] BUILD ERROR [INFO] ------------------------------------------------------------------------ [INFO] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.2.1:prepare
          Hide
          Simon Brandhof added a comment -

          Hi Jean Paul, do you have dependencies or extensions on org.apache.maven.wagon ? It seems to be the origin of the problem, since wagon has been included into maven 2.0.9.

          Show
          Simon Brandhof added a comment - Hi Jean Paul, do you have dependencies or extensions on org.apache.maven.wagon ? It seems to be the origin of the problem, since wagon has been included into maven 2.0.9.
          Hide
          Jean-Paul GUIGUI added a comment -

          Hi Simon,

          Thanks a lot. Indeed you are right, in the POM of the project there was still the Wagon extension.
          It used to work with maven 2.0.8 but not anymore with maven 2.0.9. By removing Wagon extension from the POM, the sonar plugin is now working properly with maven 2.0.9.

          Thanks,
          Jean-Paul

          Show
          Jean-Paul GUIGUI added a comment - Hi Simon, Thanks a lot. Indeed you are right, in the POM of the project there was still the Wagon extension. It used to work with maven 2.0.8 but not anymore with maven 2.0.9. By removing Wagon extension from the POM, the sonar plugin is now working properly with maven 2.0.9. Thanks, Jean-Paul
          Hide
          Simon Brandhof added a comment -

          As commented, the workaround is to remove the wagon-webdav extension from poms.

          Show
          Simon Brandhof added a comment - As commented, the workaround is to remove the wagon-webdav extension from poms.
          Hide
          Christophe Lallement added a comment -

          Hi

          Excuse me Simon, but I'm not agree with you decision.
          Maven & sonar are tools design to be used into open source world but also into professional world.
          In professional world (like my company) we try to enforce tools like maven sonar ant archiva (its so difficult to evangelism .. )

          As describe into sonatype maven guide, we have a private repository to deploy our private jar. (we use archiva)
          To deploy into archiva we use webdav plug in (we tried with scp, but too many pb with file right on repository).
          maven 2.0.8 has a big pb. it already check snapshot and plug in version on all repository. Now we have many project and performance are very poor.
          This bugs is fix in 2.0.9

          All future maven version will have a the webdav plugin. You can not close the door to this future version for people which use webdav plugin ?
          I think you can not just close this issue. Maybe there is a workaround by playing with profile ....

          Regards
          Christophe

          Show
          Christophe Lallement added a comment - Hi Excuse me Simon, but I'm not agree with you decision. Maven & sonar are tools design to be used into open source world but also into professional world. In professional world (like my company) we try to enforce tools like maven sonar ant archiva (its so difficult to evangelism .. ) As describe into sonatype maven guide, we have a private repository to deploy our private jar. (we use archiva) To deploy into archiva we use webdav plug in (we tried with scp, but too many pb with file right on repository). maven 2.0.8 has a big pb. it already check snapshot and plug in version on all repository. Now we have many project and performance are very poor. This bugs is fix in 2.0.9 All future maven version will have a the webdav plugin. You can not close the door to this future version for people which use webdav plugin ? I think you can not just close this issue. Maybe there is a workaround by playing with profile .... Regards Christophe
          Hide
          Simon Brandhof added a comment -

          Hi Christophe,

          Of course sonar does not forbid to use webdav. The workaround is to remove a useless <extension> definition because it's already integrated to the maven core. Projects can always use webdav. Moreover the sonar project itself offers proof that it works. We build sonar with maven 2.0.9, deploy it on codehaus webdav repositories and execute sonar on sonar...

          Do you agree ?

          Show
          Simon Brandhof added a comment - Hi Christophe, Of course sonar does not forbid to use webdav. The workaround is to remove a useless <extension> definition because it's already integrated to the maven core. Projects can always use webdav. Moreover the sonar project itself offers proof that it works. We build sonar with maven 2.0.9, deploy it on codehaus webdav repositories and execute sonar on sonar... Do you agree ?
          Hide
          Sebastian Annies added a comment -

          We are using koshuke's svn wagon provider. Same case here and it's not included in the maven 2.0.9 or in some later version. Hmm - how to workaround inthis case? Any suggestion?

          Show
          Sebastian Annies added a comment - We are using koshuke's svn wagon provider. Same case here and it's not included in the maven 2.0.9 or in some later version. Hmm - how to workaround inthis case? Any suggestion?
          Hide
          Freddy Mallet added a comment -

          In fact the problem is a lot more critic that what we imagined.

          The exception seems to be raised each time an extension is defined in the pom and the number of classes contained in the jar extension is important.

          Show
          Freddy Mallet added a comment - In fact the problem is a lot more critic that what we imagined. The exception seems to be raised each time an extension is defined in the pom and the number of classes contained in the jar extension is important.
          Hide
          Freddy Mallet added a comment -

          We don't know why, but the problem doesn't occur with Maven 2.0.7. This can be considered as a temporary workaround.

          Show
          Freddy Mallet added a comment - We don't know why, but the problem doesn't occur with Maven 2.0.7. This can be considered as a temporary workaround.
          Hide
          Tom van den Berge added a comment -

          I've the same problem.

          I also had the wagon extension, but removing it didn't change anything. I'm using sonar 1.5.1 and maven 2.0.9.
          Running on Mac OSX (intel), Java 1.5.

          Show
          Tom van den Berge added a comment - I've the same problem. I also had the wagon extension, but removing it didn't change anything. I'm using sonar 1.5.1 and maven 2.0.9. Running on Mac OSX (intel), Java 1.5.
          Hide
          Freddy Mallet added a comment -

          Hello Tom, in fact this problem occurs each time a maven extension is defined in the pom file. Do you confirm you have others extensions defined ?

          thanks
          Freddy

          Show
          Freddy Mallet added a comment - Hello Tom, in fact this problem occurs each time a maven extension is defined in the pom file. Do you confirm you have others extensions defined ? thanks Freddy
          Hide
          Tom van den Berge added a comment -

          Hi Freddy,
          I'm afraid I have to say that my pom file does not use any extensions at all.

          The only 'strange' thing about the pom is that is uses a parent pom (which also does not have any extensions).

          If you want I can send you the pom and its parent pom file.

          Show
          Tom van den Berge added a comment - Hi Freddy, I'm afraid I have to say that my pom file does not use any extensions at all. The only 'strange' thing about the pom is that is uses a parent pom (which also does not have any extensions). If you want I can send you the pom and its parent pom file.
          Hide
          Freddy Mallet added a comment -

          Hi Tom, it would be a great help if you could send a maven project example (without extension) to reproduce this exception. Just for information, this bug seems to be related to the way we use Maven Embedder.
          Thanks,
          Freddy

          Show
          Freddy Mallet added a comment - Hi Tom, it would be a great help if you could send a maven project example (without extension) to reproduce this exception. Just for information, this bug seems to be related to the way we use Maven Embedder. Thanks, Freddy
          Hide
          Tom van den Berge added a comment -

          Freddy, I've just sent you the pom files that give me the stack overflow.

          It might have something to do with the <parent> relationship between the two files. I have merged the two pom files into one file, and then the stack overflow doesn't occur!

          Show
          Tom van den Berge added a comment - Freddy, I've just sent you the pom files that give me the stack overflow. It might have something to do with the <parent> relationship between the two files. I have merged the two pom files into one file, and then the stack overflow doesn't occur!
          Hide
          Fabrice Daugan added a comment -

          I've the same behavior (same trace).
          Also, i have some plugin extension, but parent pom too with module.
          The sonar goal is executed on my plugin A.
          P1 parentOf P2 parentOf P3 parentOf P3 havingModule M1 parentOf A

          I don't think so this error is due to extensionq, but is due to parent relationships resolution.
          Relevant trace :
          [INFO] [cobertura:cobertura]
          [INFO] Cobertura Report generation was successful.
          [INFO] snapshot fr.gfi.forge.pom.projects:csn-jar-projects-parent:1.0.3-SNAPSHOT: checking for updates from csn.snapshots
          [INFO] snapshot fr.gfi.forge.pom.projects:csn-abstract-projects-parent:1.0.3-SNAPSHOT: checking for updates from csn.snapshots
          [INFO] snapshot fr.gfi.forge.pom.project:csn-projects-parent:1.0.3-SNAPSHOT: checking for updates from csn.snapshots
          [ERROR] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.6:collect
          java.lang.StackOverflowError
          at java.util.zip.ZipFile.getEntry(ZipFile.java:148)
          at java.util.jar.JarFile.getEntry(JarFile.java:206)
          at java.util.jar.JarFile.getJarEntry(JarFile.java:189)
          at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:754)
          at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:732)
          at sun.misc.URLClassPath.findResource(URLClassPath.java:145)
          at java.net.URLClassLoader$2.run(URLClassLoader.java:362)
          at java.security.AccessController.doPrivileged(Native Method)
          at java.net.URLClassLoader.findResource(URLClassLoader.java:359)
          at org.codehaus.classworlds.RealmClassLoader.findResource(RealmClassLoader.java:232)
          at java.lang.ClassLoader.getResource(ClassLoader.java:978)
          at org.codehaus.classworlds.RealmClassLoader.getResourceDirect(RealmClassLoader.java:247)
          at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:300)
          at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237)
          at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288)
          at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314)
          at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237)
          ...

          Show
          Fabrice Daugan added a comment - I've the same behavior (same trace). Also, i have some plugin extension, but parent pom too with module. The sonar goal is executed on my plugin A. P1 parentOf P2 parentOf P3 parentOf P3 havingModule M1 parentOf A I don't think so this error is due to extensionq, but is due to parent relationships resolution. Relevant trace : [INFO] [cobertura:cobertura] [INFO] Cobertura Report generation was successful. [INFO] snapshot fr.gfi.forge.pom.projects:csn-jar-projects-parent:1.0.3-SNAPSHOT: checking for updates from csn.snapshots [INFO] snapshot fr.gfi.forge.pom.projects:csn-abstract-projects-parent:1.0.3-SNAPSHOT: checking for updates from csn.snapshots [INFO] snapshot fr.gfi.forge.pom.project:csn-projects-parent:1.0.3-SNAPSHOT: checking for updates from csn.snapshots [ERROR] Cannot execute the command org.codehaus.sonar:sonar-core-maven-plugin:1.6:collect java.lang.StackOverflowError at java.util.zip.ZipFile.getEntry(ZipFile.java:148) at java.util.jar.JarFile.getEntry(JarFile.java:206) at java.util.jar.JarFile.getJarEntry(JarFile.java:189) at sun.misc.URLClassPath$JarLoader.getResource(URLClassPath.java:754) at sun.misc.URLClassPath$JarLoader.findResource(URLClassPath.java:732) at sun.misc.URLClassPath.findResource(URLClassPath.java:145) at java.net.URLClassLoader$2.run(URLClassLoader.java:362) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findResource(URLClassLoader.java:359) at org.codehaus.classworlds.RealmClassLoader.findResource(RealmClassLoader.java:232) at java.lang.ClassLoader.getResource(ClassLoader.java:978) at org.codehaus.classworlds.RealmClassLoader.getResourceDirect(RealmClassLoader.java:247) at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:300) at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237) at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:288) at org.codehaus.classworlds.DefaultClassRealm.getResource(DefaultClassRealm.java:314) at org.codehaus.classworlds.RealmClassLoader.getResource(RealmClassLoader.java:237) ...
          Hide
          Fabrice Daugan added a comment -

          An important thing, this error stills exist on 1.6

          Show
          Fabrice Daugan added a comment - An important thing, this error stills exist on 1.6
          Hide
          Anders Bakkevold added a comment -

          I also have this problem on some projects, with Sonar 1.6 and maven 2.0.9 or 2.0.10. I use maven 2.0.8 as a work-around.
          The projects that fail are multi-module.

          Show
          Anders Bakkevold added a comment - I also have this problem on some projects, with Sonar 1.6 and maven 2.0.9 or 2.0.10. I use maven 2.0.8 as a work-around. The projects that fail are multi-module.
          Hide
          Henri Gomez added a comment -

          I got a problem with Sonar 1.6, maven DAV wagon and m2eclipse.

          We're using both maven 2.0.10 and m2eclipse 0.9.7.

          In our top pom we used to add :

          <extensions>
          <!-- Make use of WEB-DAV plugin for deployement -->
          <extension>
          <groupId>org.apache.maven.wagon</groupId>
          <artifactId>wagon-webdav</artifactId>
          <version>1.0-beta-2</version>
          </extension>
          </extensions>

          This one allow us to deploy our artifact to both Nexus with maven
          2.0.10 and m2eclipse.
          As of maven 2.0.9 it's no more mandatory.

          With my first tests with sonar, I got problems with it so I removed
          from on top pom and everything works fine till we're using maven
          2.0.10.

          But m2eclipse use a pre maven 2-1 embedded and this one require wagon-webdav.

          Any way to get this wagon-webdav / sonar problem fixed since it prevent us now to use sonar, which is sad since it's a great tool.

          Show
          Henri Gomez added a comment - I got a problem with Sonar 1.6, maven DAV wagon and m2eclipse. We're using both maven 2.0.10 and m2eclipse 0.9.7. In our top pom we used to add : <extensions> <!-- Make use of WEB-DAV plugin for deployement --> <extension> <groupId>org.apache.maven.wagon</groupId> <artifactId>wagon-webdav</artifactId> <version>1.0-beta-2</version> </extension> </extensions> This one allow us to deploy our artifact to both Nexus with maven 2.0.10 and m2eclipse. As of maven 2.0.9 it's no more mandatory. With my first tests with sonar, I got problems with it so I removed from on top pom and everything works fine till we're using maven 2.0.10. But m2eclipse use a pre maven 2-1 embedded and this one require wagon-webdav. Any way to get this wagon-webdav / sonar problem fixed since it prevent us now to use sonar, which is sad since it's a great tool.
          Hide
          Henri Gomez added a comment -

          It's fixed in the latest trunk ?

          Show
          Henri Gomez added a comment - It's fixed in the latest trunk ?
          Hide
          Simon Brandhof added a comment -

          Not completely, otherwise the ticket would be fixed ;o)
          But good news, 90% of the work are done. We'll release a milestone next days. Please stay tuned.

          Show
          Simon Brandhof added a comment - Not completely, otherwise the ticket would be fixed ;o) But good news, 90% of the work are done. We'll release a milestone next days. Please stay tuned.
          Hide
          Henri Gomez added a comment -

          Good news.

          Please send a note on sonar-user list so I could grab the milestone and check it.

          Regards

          Show
          Henri Gomez added a comment - Good news. Please send a note on sonar-user list so I could grab the milestone and check it. Regards
          Hide
          Simon Brandhof added a comment -

          I'm so happy to fix this issue that I'm gonna cry ;o)

          Show
          Simon Brandhof added a comment - I'm so happy to fix this issue that I'm gonna cry ;o)
          Hide
          Henri Gomez added a comment -

          Congrats !

          You could cry now

          When is expected the 1.8 milestone ?

          Show
          Henri Gomez added a comment - Congrats ! You could cry now When is expected the 1.8 milestone ?
          Hide
          Olivier Gaudin added a comment -

          He did cry, I witnessed !!

          Show
          Olivier Gaudin added a comment - He did cry, I witnessed !!

            People

            • Assignee:
              Simon Brandhof
              Reporter:
              Simon Brandhof
            • Votes:
              11 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: