Maven Javadoc Plugin
  1. Maven Javadoc Plugin
  2. MJAVADOC-398

Classes from build output directory can cause failure

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.9.1
    • Fix Version/s: 2.10
    • Component/s: None
    • Labels:
      None

      Description

      maven-javadoc-plugin adds compiled classes from build output directory to javadoc's classpath. There are certain cases when this can lead to either incorrect serialized-form.html page or failure (in case of jdk8). See [1] for more details. I think that having classes from build output directory on javadoc's classpath is not necessary. It may cause only problems and user can call javadoc:javadoc before actual build anyway.

      [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1113877

        Issue Links

          Activity

          Hide
          Michal Srb added a comment -
          Show
          Michal Srb added a comment - I've opened PR on github: https://github.com/apache/maven-plugins/pull/25
          Hide
          Michael Osipov added a comment -

          Michal, I am about to commit your change. One more thing, where is the point of including the built class files to the classpath of javadoc if you already provide the sources anyway?

          Show
          Michael Osipov added a comment - Michal, I am about to commit your change. One more thing, where is the point of including the built class files to the classpath of javadoc if you already provide the sources anyway?
          Hide
          Michael Osipov added a comment -

          Fixed with r1609274.

          Show
          Michael Osipov added a comment - Fixed with r1609274.
          Hide
          Michal Srb added a comment -

          Thanks!

          Show
          Michal Srb added a comment - Thanks!
          Hide
          David Liszewski added a comment -

          I do wonder if history will show this to be an ill-advised change.

          Regard
          http://stackoverflow.com/questions/25983852/maven-javadoc-plugin-breaks-mvn-releaseperform/25986409#25986409
          http://stackoverflow.com/questions/25971832/javadoc-generation-failed-classcastexception-com-sun-tools-javadoc-classdocim
          http://jira.codehaus.org/browse/MJAVADOC-406

          I fail to understand how it was your responsibility to provide a work-around for an unresolved defect in java-1.8.0-openjdk.

          Yes, I know we should be pinning plug-in versions. For certain, this is a wake-up call for the community to change their behavior, but it was a rather rude awakening. We'll be editing a few hundred files so we can make update releases for our clients. Multiply that by the number of users of this plugin.

          The grief reported on StackOverflow is but a tip of the iceberg.

          Show
          David Liszewski added a comment - I do wonder if history will show this to be an ill-advised change. Regard http://stackoverflow.com/questions/25983852/maven-javadoc-plugin-breaks-mvn-releaseperform/25986409#25986409 http://stackoverflow.com/questions/25971832/javadoc-generation-failed-classcastexception-com-sun-tools-javadoc-classdocim http://jira.codehaus.org/browse/MJAVADOC-406 I fail to understand how it was your responsibility to provide a work-around for an unresolved defect in java-1.8.0-openjdk . Yes, I know we should be pinning plug-in versions. For certain, this is a wake-up call for the community to change their behavior, but it was a rather rude awakening. We'll be editing a few hundred files so we can make update releases for our clients. Multiply that by the number of users of this plugin. The grief reported on StackOverflow is but a tip of the iceberg.
          Hide
          Michael Osipov added a comment - - edited

          Hi David,

          thanks for your report. At best, we would have two test cases, one which makes Maven fail when classes are present and one which makes it fail when classes are missing. This could be added to an IT. I will have a look at MJAVADOC-406 in the next days.

          Show
          Michael Osipov added a comment - - edited Hi David, thanks for your report. At best, we would have two test cases, one which makes Maven fail when classes are present and one which makes it fail when classes are missing. This could be added to an IT. I will have a look at MJAVADOC-406 in the next days.
          Hide
          Michal Srb added a comment -

          Hello guys,

          I would like to deeply apologize to everyone affected by this issue. I should have been more attentive.

          Here's what really happened:

          I proposed this change:
          https://github.com/apache/maven-plugins/pull/25/files
          But from some reason, different change ended up in maven-plugins repo:
          https://github.com/apache/maven-plugins/commit/102c98d6f519736b832deb0ae67e1a01bad1b1c0

          I guess it must have been some unfortunate mistake or glitch in some tool. I am truly sorry for all the inconvenience caused by this.

          Show
          Michal Srb added a comment - Hello guys, I would like to deeply apologize to everyone affected by this issue. I should have been more attentive. Here's what really happened: I proposed this change: https://github.com/apache/maven-plugins/pull/25/files But from some reason, different change ended up in maven-plugins repo: https://github.com/apache/maven-plugins/commit/102c98d6f519736b832deb0ae67e1a01bad1b1c0 I guess it must have been some unfortunate mistake or glitch in some tool. I am truly sorry for all the inconvenience caused by this.
          Hide
          Michael Osipov added a comment -

          Dammit, I have, indeed, deleted the wrong line without noticing it.

          Show
          Michael Osipov added a comment - Dammit, I have, indeed, deleted the wrong line without noticing it.
          Hide
          Hervé Boutemy added a comment - - edited

          notice that it is another proof of some well known good practice that is so hard to do on daily operations:

          don't fix anything without previously creating an IT to prove that the fix does the expected job

          I know that it's really rude, because for such little fixes, creating the IT is much more work than the fix itself
          and some people tend to not understand why patches told fixing something are not applied

          experience learned the hard way (TM): you're not the first, that's something you won't forget

          Show
          Hervé Boutemy added a comment - - edited notice that it is another proof of some well known good practice that is so hard to do on daily operations: don't fix anything without previously creating an IT to prove that the fix does the expected job I know that it's really rude, because for such little fixes, creating the IT is much more work than the fix itself and some people tend to not understand why patches told fixing something are not applied experience learned the hard way (TM): you're not the first, that's something you won't forget
          Hide
          Michael Osipov added a comment -

          Hervé Boutemy,

          true words. Very true. That would ultimately mean that we need to require a test case from the reporters in order to process the bug and finally fix it with an IT. Even it is so simple to fix.

          Show
          Michael Osipov added a comment - Hervé Boutemy , true words. Very true. That would ultimately mean that we need to require a test case from the reporters in order to process the bug and finally fix it with an IT. Even it is so simple to fix.

            People

            • Assignee:
              Michael Osipov
              Reporter:
              Michal Srb
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development