jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • Maven 2 & 3
  • MNG-4731

NPE from AttachedArtifact.getVersion rather than meaningful error

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.2.1
  • Fix Version/s: Issues to be reviewed for 3.x
  • Component/s: Errors
  • Labels:
    None
  • Environment:
    Ubuntu Lucid, JDK 6u21
  • Complexity:
    Intermediate
  • Testcase included:
    yes
  • Patch Submitted:
    Yes

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)
...
  • Options
    • Sort By Name
    • Sort By Date
    • Ascending
    • Descending
    • Download All

Attachments

  1. File
    validateIdentity.diff
    14/Jul/10 1:38 PM
    4 kB
    Jesse Glick

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Benjamin Bentmann added a comment - 14/Jul/10 1:43 PM

As a side note, the stack trace suggests the plugin is directly accessing AttachedArtifact which isn't expected either. MavenProjectHelper.attachArtifact() should be used instead.

Show
Benjamin Bentmann added a comment - 14/Jul/10 1:43 PM As a side note, the stack trace suggests the plugin is directly accessing AttachedArtifact which isn't expected either. MavenProjectHelper.attachArtifact() should be used instead.
Hide
Permalink
Jesse Glick added a comment - 14/Jul/10 2:13 PM

If AttachedArtifact is not supposed to be accessed directly by plugins, it should not have been made public I guess. But I will pass on the advice.

Show
Jesse Glick added a comment - 14/Jul/10 2:13 PM If AttachedArtifact is not supposed to be accessed directly by plugins, it should not have been made public I guess. But I will pass on the advice.
Hide
Permalink
Milos Kleint added a comment - 15/Jul/10 2:53 AM

Benjamin, unfortunately the MavenProjectHelper requires a MavenProject instance as parameter which I don't have for the artifact in this case so I just copied the code from MavenProjectHelper at some point in time.

Show
Milos Kleint added a comment - 15/Jul/10 2:53 AM Benjamin, unfortunately the MavenProjectHelper requires a MavenProject instance as parameter which I don't have for the artifact in this case so I just copied the code from MavenProjectHelper at some point in time.

People

  • Assignee:
    Unassigned
    Reporter:
    Jesse Glick
Vote (0)
Watch (1)

Dates

  • Created:
    14/Jul/10 1:38 PM
    Updated:
    20/Sep/10 11:10 AM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.