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

Javadoc publishing fails on consecutive successful builds

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Component/s: core
    • Labels:
      None
    • Environment:
      Hudson 1.355, Windows Server 2008

      Description

      I am having the problem that Javadoc publishing fails after the first successful build. That is, build #1 succeeds and publishes Javadoc, but build #2 onwards fails with the following error:

      ERROR: No javadoc found in C:\Program Files\Hudson\jobs\FLTools\workspace\docs/api/html: null

      I found however that after deleting the published Javadoc directory, C:\Program Files\Hudson\jobs\FLTools\javadoc, the build succeeds again. Therefore, it looks like Hudson is having problems overwriting previously published Javadoc.

        Activity

        Hide
        mindless Alan Harder added a comment -

        This will happen if the javadoc directory in your job's workspace is exactly the same as it was for the previous build (ie, there is nothing new to copy..). Does your job skip javadoc generation when it sees javadoc from a previous run? Can you do a "clean" build to force javadoc to run again?

        Show
        mindless Alan Harder added a comment - This will happen if the javadoc directory in your job's workspace is exactly the same as it was for the previous build (ie, there is nothing new to copy..). Does your job skip javadoc generation when it sees javadoc from a previous run? Can you do a "clean" build to force javadoc to run again?
        Hide
        aknuds1 Arve Knudsen added a comment -

        The buildsystem only regenerates the API documentation if the sources have changed, as one would expect?? Are you saying it's a feature of Hudson to break the build if the Javadoc hasn't changed since last time? I could of course force regeneration of the docs, but I'd rather see the bug fixed (unless it's considered a feature??).

        Show
        aknuds1 Arve Knudsen added a comment - The buildsystem only regenerates the API documentation if the sources have changed, as one would expect?? Are you saying it's a feature of Hudson to break the build if the Javadoc hasn't changed since last time? I could of course force regeneration of the docs, but I'd rather see the bug fixed (unless it's considered a feature??).
        Hide
        mindless Alan Harder added a comment -

        Not a feature, just a side-effect of the code interpreting "zero files copied" as a configuration or communication error.. it doesn't distinguish this from "all files were already current". I think the common usage is to have Hudson run clean builds each time, so this issue hasn't come up before.. so I'd consider it a lower priority item (a patch to fix it is welcome, of course )

        Show
        mindless Alan Harder added a comment - Not a feature, just a side-effect of the code interpreting "zero files copied" as a configuration or communication error.. it doesn't distinguish this from "all files were already current". I think the common usage is to have Hudson run clean builds each time, so this issue hasn't come up before.. so I'd consider it a lower priority item (a patch to fix it is welcome, of course )
        Hide
        aknuds1 Arve Knudsen added a comment -

        It sounds weird to me, coming from Buildbot, that the common case is to perform clean builds each time? That can really slow down the time taken to verify a checkin, which doesn't seem like what you want. In Buildbot the typical job builds incrementally while you typically have a nightly job that does a clean checkout and does more in-depth checking. I'll have my job clean the Javadoc though before building, as a workaround.

        Show
        aknuds1 Arve Knudsen added a comment - It sounds weird to me, coming from Buildbot, that the common case is to perform clean builds each time? That can really slow down the time taken to verify a checkin, which doesn't seem like what you want. In Buildbot the typical job builds incrementally while you typically have a nightly job that does a clean checkout and does more in-depth checking. I'll have my job clean the Javadoc though before building, as a workaround.
        Hide
        scm_issue_link SCM/JIRA link daemon added a comment -

        Code changed in hudson
        User: : mindless
        Path:
        trunk/hudson/main/core/src/main/java/hudson/FilePath.java
        trunk/hudson/main/core/src/test/java/hudson/FilePathTest.java
        trunk/www/changelog.html
        http://jenkins-ci.org/commit/30450
        Log:
        [FIXED JENKINS-6332] for 1.357
        Add setOverwrite(true) for local->local copy in FilePath.copyRecursiveTo().
        This makes it consistent with master/slave copy (either direction),
        and also avoids returning 0 if all files already have current/newer timestamp
        which some code (javadoc publishing, copyartifact plugin) would interpret as
        copy failure or no matching files found.

        Show
        scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : mindless Path: trunk/hudson/main/core/src/main/java/hudson/FilePath.java trunk/hudson/main/core/src/test/java/hudson/FilePathTest.java trunk/www/changelog.html http://jenkins-ci.org/commit/30450 Log: [FIXED JENKINS-6332] for 1.357 Add setOverwrite(true) for local->local copy in FilePath.copyRecursiveTo(). This makes it consistent with master/slave copy (either direction), and also avoids returning 0 if all files already have current/newer timestamp which some code (javadoc publishing, copyartifact plugin) would interpret as copy failure or no matching files found.

          People

          • Assignee:
            mindless Alan Harder
            Reporter:
            aknuds1 Arve Knudsen
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: