Maven 2.x Invoker Plugin

Error installing artifact's metadata

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Critical Critical
  • Resolution: Won't Fix
  • Affects Version/s: None
  • Fix Version/s: None
  • Labels:
    None
  • Testcase included:
    yes
  • Patch Submitted:
    Yes
  • Number of attachments :
    1

Description

Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata

end tag not allowed in epilog but got / (position: END_TAG seen ...\n

Looks like there might be an issue with updates to maven-metadata-local.xml during the mvn install task. we have a build server that is multi threaded. we often see this in the

</versioning>
</metadata>
</metadata>

maven-metadata-local.xml.

maybe a solution is to add maven-metadata-local.xml.lock to ensure two threads don't update the file at the same time

Issue Links

is related to

Bug - A problem which impairs or prevents the functions of the product. MINSTALL-54 [INFO] Error installing artifact's metadata

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Geoff Simpson added a comment -

note that there is a duplicate report here http://jira.codehaus.org/browse/MINSTALL-54 but as the fix is inside this project i've raised a second bug report here.

Show
Geoff Simpson added a comment - note that there is a duplicate report here http://jira.codehaus.org/browse/MINSTALL-54 but as the fix is inside this project i've raised a second bug report here.
Hide
Permalink
Benjamin Bentmann added a comment -

The recommended practice for the Invoker is to use a private local repository somewhere inside the project's output directory where concurrency concerns should not apply. Hence, I am tempted to close this as won't fix.

Show
Benjamin Bentmann added a comment - The recommended practice for the Invoker is to use a private local repository somewhere inside the project's output directory where concurrency concerns should not apply. Hence, I am tempted to close this as won't fix.
Hide
Permalink
John Sipher added a comment -

I understand the point about the recommended practice, but...

The proposed fix - adding maven-metadata-local.xml.lock - seems pretty simple. Why not go ahead and fix it and save people like me the trouble of researching the problem and figuring out a workaround?

I think there are probably a lot of Maven users like me that just want to use the tool without making a career out of understanding all the ins and outs. That's possible because great tools like Maven "will run with sensible defaults" (see http://maven.apache.org/run-maven/index.html#Quick_Start for quote). In this case Maven doesn't run (at least not reliably) with the default behavior, and I'm using up a good chunk of my Sunday trying to figure out a workaround that won't break something else.

Show
John Sipher added a comment - I understand the point about the recommended practice, but... The proposed fix - adding maven-metadata-local.xml.lock - seems pretty simple. Why not go ahead and fix it and save people like me the trouble of researching the problem and figuring out a workaround? I think there are probably a lot of Maven users like me that just want to use the tool without making a career out of understanding all the ins and outs. That's possible because great tools like Maven "will run with sensible defaults" (see http://maven.apache.org/run-maven/index.html#Quick_Start for quote). In this case Maven doesn't run (at least not reliably) with the default behavior, and I'm using up a good chunk of my Sunday trying to figure out a workaround that won't break something else.
Hide
Permalink
Robert Scholte added a comment -

I agree with Benjamin.
Also, when comparing the overhead/costs of IO, synchronized methods (which only works within the same JVM), sleeps and timeouts with the chance that this situation occurs, IMHO it's not worth it.

Show
Robert Scholte added a comment - I agree with Benjamin. Also, when comparing the overhead/costs of IO, synchronized methods (which only works within the same JVM), sleeps and timeouts with the chance that this situation occurs, IMHO it's not worth it.

People

  • Assignee:
    Robert Scholte
    Reporter:
    Geoff Simpson
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: