Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-22051

build.xml not created after successful build

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Critical
    • Resolution: Cannot Reproduce
    • 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)

    Description

      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...

      Attachments

        Issue Links

          Activity

            oleg_nenashev 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 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.
            danielbeck 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.

            danielbeck 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.
            pgbakker 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

            pgbakker 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
            danielbeck 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.

            danielbeck 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.
            danielbeck 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.

            danielbeck 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.

            People

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

              Dates

                Created:
                Updated:
                Resolved: