Uploaded image for project: 'Maven'
  1. Maven
  2. MNG-4731

NPE from AttachedArtifact.getVersion rather than meaningful error

    XMLWordPrintableJSON

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Incomplete
    • Affects Version/s: 2.2.1
    • Fix Version/s: None
    • Component/s: Errors
    • Labels:
      None
    • Environment:
      Ubuntu Lucid, JDK 6u21
    • Flags:
      Patch

      Description

      I am working on a problem with nbm:populate-repository (from org.codehaus.mojo:nbm-maven-plugin). Maven 2.2.1, when run under certain circumstances, fails when running this goal with the following unhelpful message:

      ...
      [ERROR] FATAL ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] null
      [INFO] ------------------------------------------------------------------------
      [INFO] Trace
      java.lang.NullPointerException
      	at org.apache.maven.project.artifact.AttachedArtifact.getVersion(AttachedArtifact.java:122)
      	at org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:141)
      	at org.apache.maven.artifact.DefaultArtifact.<init>(DefaultArtifact.java:122)
      	at org.apache.maven.project.artifact.AttachedArtifact.<init>(AttachedArtifact.java:42)
      	at org.codehaus.mojo.nbm.PopulateRepositoryMojo.createAttachedArtifact(PopulateRepositoryMojo.java:617)
      	at org.codehaus.mojo.nbm.PopulateRepositoryMojo.execute(PopulateRepositoryMojo.java:424)
      ...
      

      Inspection of the code reveals the immediate cause of the NPE: in getVersion, the parent field is null. Even though this is a final field set in the constructor to a non-null value, it has not yet been set when the super constructor is called. This is because DefaultArtifact uses the antipattern of calling an overridable method (getVersion) from its constructor (indirectly via validateIdentity). The NPE then prevents the details of the problem from being reported to the user.

      Ideally this antipattern would be solved, by making validateIdentity public and requiring all creators of a DefaultArtifact to call it after construction. Since this cannot now be done compatibly (e.g. PopulateRepositoryMojo above would need to be modified), the next best thing is to assume that AttachedArtifact is the only subclass, and ensure that validateIdentity is called only once the object has been fully constructed. With that change (patch against 2.2.2-SNAPSHOT attached), the error message is informative (specifics of this run have been elided) and points toward possible problems in the plugin:

      ...
      [ERROR] FATAL ERROR
      [INFO] ------------------------------------------------------------------------
      [INFO] An invalid artifact was detected.
      
      This artifact might be in your project's POM, or it might have been included transitively
      during the resolution process. Here is the information we do have for this artifact:
      
          o GroupID:     ...
          o ArtifactID:  ...
          o Version:     ...
          o Type:        <<< MISSING >>>
      
      [INFO] ------------------------------------------------------------------------
      [INFO] Trace
      org.apache.maven.artifact.InvalidArtifactRTException: For artifact {...:...:...:null}: The type cannot be empty.
      	at org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:141)
      	at org.apache.maven.project.artifact.AttachedArtifact.validateIdentity(AttachedArtifact.java:63)
      	at org.apache.maven.project.artifact.AttachedArtifact.<init>(AttachedArtifact.java:53)
      	at org.codehaus.mojo.nbm.PopulateRepositoryMojo.createAttachedArtifact(PopulateRepositoryMojo.java:617)
      	at org.codehaus.mojo.nbm.PopulateRepositoryMojo.execute(PopulateRepositoryMojo.java:424)
      ...
      

        Attachments

        1. validateIdentity.diff
          4 kB
          Jesse N. Glick

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                jglick Jesse N. Glick
              • Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: