• Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Critical Critical
    • None
    • Microsoft Windows [Version 6.1.7601]

      java version "1.7.0_40"
      Java(TM) SE Runtime Environment (build 1.7.0_40-b43)
      Java HotSpot(TM) 64-Bit Server VM (build 24.0-b56, mixed mode)

      I had the 'mailer' plugin installed, but the maven plugin (a dependancy of the mailer plugin) was disabled.

      after a successful build the following exception was occurring:

      SEVERE: Executor threw an exception
      java.lang.NoClassDefFoundError: hudson/maven/MavenBuild
      	at java.lang.Class.getDeclaredMethods0(Native Method)
      	at java.lang.Class.privateGetDeclaredMethods(Unknown Source)
      	at java.lang.Class.getDeclaredMethod(Unknown Source)
      	at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:162)
      	at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:167)
      	at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.getMethod(SerializationMethodInvoker.java:149)
      	at com.thoughtworks.xstream.converters.reflection.SerializationMethodInvoker.callWriteReplace(SerializationMethodInvoker.java:86)
      	at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:99)
      	at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
      	at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
      	at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
      	at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:88)
      	at com.thoughtworks.xstream.converters.collections.AbstractCollectionConverter.writeItem(AbstractCollectionConverter.java:64)
      	at com.thoughtworks.xstream.converters.collections.CollectionConverter.marshal(CollectionConverter.java:55)
      	at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
      	at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
      	at com.thoughtworks.xstream.core.AbstractReferenceMarshaller$1.convertAnother(AbstractReferenceMarshaller.java:84)
      	at hudson.util.RobustReflectionConverter.marshallField(RobustReflectionConverter.java:223)
      	at hudson.util.RobustReflectionConverter$2.writeField(RobustReflectionConverter.java:210)
      	at hudson.util.RobustReflectionConverter$2.visit(RobustReflectionConverter.java:182)
      	at com.thoughtworks.xstream.converters.reflection.PureJavaReflectionProvider.visitSerializableFields(PureJavaReflectionProvider.java:135)
      	at hudson.util.RobustReflectionConverter.doMarshal(RobustReflectionConverter.java:167)
      	at hudson.util.RobustReflectionConverter.marshal(RobustReflectionConverter.java:108)
      	at com.thoughtworks.xstream.core.AbstractReferenceMarshaller.convert(AbstractReferenceMarshaller.java:69)
      	at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:58)
      	at com.thoughtworks.xstream.core.TreeMarshaller.convertAnother(TreeMarshaller.java:43)
      	at com.thoughtworks.xstream.core.TreeMarshaller.start(TreeMarshaller.java:82)
      	at com.thoughtworks.xstream.core.AbstractTreeMarshallingStrategy.marshal(AbstractTreeMarshallingStrategy.java:37)
      	at com.thoughtworks.xstream.XStream.marshal(XStream.java:898)
      	at com.thoughtworks.xstream.XStream.marshal(XStream.java:887)
      	at com.thoughtworks.xstream.XStream.toXML(XStream.java:860)
      	at hudson.XmlFile.write(XmlFile.java:178)
      	at hudson.model.Run.save(Run.java:1845)
      	at hudson.model.Run.execute(Run.java:1732)
      	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
      	at hudson.model.ResourceController.execute(ResourceController.java:88)
      	at hudson.model.Executor.run(Executor.java:231)
      Caused by: java.lang.ClassNotFoundException: hudson.maven.MavenBuild
      	at org.apache.tools.ant.AntClassLoader.findClassInComponents(AntClassLoader.java:1365)
      	at org.apache.tools.ant.AntClassLoader.findClass(AntClassLoader.java:1315)
      	at org.apache.tools.ant.AntClassLoader.loadClass(AntClassLoader.java:1068)
      	at java.lang.ClassLoader.loadClass(Unknown Source)
      	... 37 more
      

      this exception was causing the build.xml file to NOT be created. which caused the build to be removed from the build history after configuration was reloaded.

      there's at least two bugs here:

      1) the mailer plugin should not cause exceptions if one of its dependencies is not enabled. either the dependency should be forced-enabled, or the mailer plugin should be disabled.

      2) jenkins should NEVER fail to write a build.xml into the build directory. regardless of what plugins throw exceptions. a build.xml should ALWAYS be created. failure to create this file results in builds getting lost from the history, and at least 30 unsolved bug reports...

          [JENKINS-22051] build.xml not created after successful build

          Oleg Nenashev added a comment - - edited

          the mailer plugin should not cause exceptions if one of its dependencies is not enabled. either the dependency should be forced-enabled, or the mailer plugin should be disabled.

          This is a common Jenkins behavior. It is not possible to check plugin dependencies excepting the runtime due to the plenty of unannotated "optional" dependencies.

          jenkins should NEVER fail to write a build.xml into the build directory. regardless of what plugins throw exceptions. a build.xml should ALWAYS be created. failure to create this file results in builds getting lost from the history, and at least 30 unsolved bug reports

          Sounds reasonable...

          I propose to leave this issue for the second case.
          Please create a separate issue for class dependencies if you don't agree.

          Oleg Nenashev added a comment - - edited the mailer plugin should not cause exceptions if one of its dependencies is not enabled. either the dependency should be forced-enabled, or the mailer plugin should be disabled. This is a common Jenkins behavior. It is not possible to check plugin dependencies excepting the runtime due to the plenty of unannotated "optional" dependencies. jenkins should NEVER fail to write a build.xml into the build directory. regardless of what plugins throw exceptions. a build.xml should ALWAYS be created. failure to create this file results in builds getting lost from the history, and at least 30 unsolved bug reports Sounds reasonable... I propose to leave this issue for the second case. Please create a separate issue for class dependencies if you don't agree.

          Daniel Beck added a comment -

          I really don't see the implied dependency of Mailer to Maven Project. I also don't understand why Mailer would influence the serialization of a build, as it stores no data in builds IIRC.

          Oleg, do you know what's going on here?


          Besides that, the issue is not caused by a failed publisher execution, but during data serialization itself, so I doubt this can be resolved at all.


          at least 30 unsolved bug reports...

          Please provide references.

          Daniel Beck added a comment - I really don't see the implied dependency of Mailer to Maven Project. I also don't understand why Mailer would influence the serialization of a build, as it stores no data in builds IIRC. Oleg, do you know what's going on here? Besides that, the issue is not caused by a failed publisher execution, but during data serialization itself, so I doubt this can be resolved at all. at least 30 unsolved bug reports... Please provide references.

          Paul Bakker added a comment - - edited

          For example some references to cases that involve builds getting lost: JENKINS-17265, JENKINS-15156 and JENKINS-11938 (all closed as not reproducible)

          Just google for "jenkins build lost" and you see how common a problem this is.

          I had the same thing happening, started comparing builds that did remain and didn't remain after a restart and saw that the onces that remained had a build.xml in the build directory and the other ones didn't.

          That triggered me to search on that and found this case. I looked at my setup and indeed the Maven Integration plugin was disabled. Once enabled again the build.xml is written again

          Paul Bakker added a comment - - edited For example some references to cases that involve builds getting lost: JENKINS-17265 , JENKINS-15156 and JENKINS-11938 (all closed as not reproducible) Just google for "jenkins build lost" and you see how common a problem this is. I had the same thing happening, started comparing builds that did remain and didn't remain after a restart and saw that the onces that remained had a build.xml in the build directory and the other ones didn't. That triggered me to search on that and found this case. I looked at my setup and indeed the Maven Integration plugin was disabled. Once enabled again the build.xml is written again

          Daniel Beck added a comment -

          The current UI does no longer allow you to disable plugins that are a dependency of other plugins, so that should take care of most of the problems due to exceptions as in the initial post.

          Daniel Beck added a comment - The current UI does no longer allow you to disable plugins that are a dependency of other plugins, so that should take care of most of the problems due to exceptions as in the initial post.

          Daniel Beck added a comment -

          Plugin loading restrictions have been extended (around Jenkins 2.24) to fail loading any plugin with unsatisfied (even implied) dependencies. The specific problem in the original report is therefore no longer a relevant issue.

           

          If something similar happens again, please file a new issue rather than reopening this one.

          Daniel Beck added a comment - Plugin loading restrictions have been extended (around Jenkins 2.24) to fail loading any plugin with unsatisfied (even implied) dependencies. The specific problem in the original report is therefore no longer a relevant issue.   If something similar happens again, please file a new issue rather than reopening this one.

            Unassigned Unassigned
            spongman spong man
            Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: