Maven 2 & 3

Build failed due to an empty or corrupt metadata file in the repository

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0
  • Fix Version/s: 2.0.1
  • Component/s: None
  • Labels:
    None
  • Complexity:
    Expert
  • Number of attachments :
    0

Description

Build failed due to an empty or corrupt metadata file in the repository. Possibly had a network error whilst downloading the metadata file. The stack trace that occurred when the error was encountered was as follows.

+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] ----------------------------------------------------------------------------
[INFO] Building Maven Ear plugin
[INFO] task-segment: [clean, install]
[INFO] ----------------------------------------------------------------------------
[INFO] [clean:clean]
[INFO] ----------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ----------------------------------------------------------------------------
[INFO] The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found
[INFO] ----------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1124)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.getMojoDescriptor(DefaultLifecycleExecutor.java:1356)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.bindLifecycleForPackaging(DefaultLifecycleExecutor.java:896)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.constructLifecycleMappings(DefaultLifecycleExecutor.java:862)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:447)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:316)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.version.PluginVersionNotFoundException: The plugin 'org.apache.maven.plugins:maven-resources-plugin' does not exist or no valid version could be found
at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:225)
at org.apache.maven.plugin.version.DefaultPluginVersionManager.resolvePluginVersion(DefaultPluginVersionManager.java:87)
at org.apache.maven.plugin.DefaultPluginManager.verifyPlugin(DefaultPluginManager.java:158)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.verifyPlugin(DefaultLifecycleExecutor.java:1095)
... 18 more
[INFO] ----------------------------------------------------------------------------
[INFO] Total time: < 1 second
[INFO] Finished at: Tue Oct 25 15:33:37 BST 2005
[INFO] Final Memory: 1M/3M
[INFO] ----------------------------------------------------------------------------

Issue Links

This issue relates to:
MNG-3415 Transfer errors cause junk metadata in the local repo Major Closed
This issue is depended upon by:
MNG-2712 update policy 'daily' not honored Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

Something is causing the metadata in the local repository to be corrupted. This has two implications:

1. Subsequent builds will pickup the empty metadata file, and fail to resolve a version. If this is a snapshot artifact, it should fix itself. If it's not, I'm not at all sure that it will.

2. This could potentially overwrite locally installed versions, erasing that information.

We just need to be more careful when downloading metadata files, and somehow verify that no errors occurred during transfer before we replace any existing file in the local repository. I'm not sure why this is happening, but it's better to address it at the WagonManager level, since that will make it harder to introduce new permutations for corrupting metadata.

Show
John Casey added a comment - Something is causing the metadata in the local repository to be corrupted. This has two implications: 1. Subsequent builds will pickup the empty metadata file, and fail to resolve a version. If this is a snapshot artifact, it should fix itself. If it's not, I'm not at all sure that it will. 2. This could potentially overwrite locally installed versions, erasing that information. We just need to be more careful when downloading metadata files, and somehow verify that no errors occurred during transfer before we replace any existing file in the local repository. I'm not sure why this is happening, but it's better to address it at the WagonManager level, since that will make it harder to introduce new permutations for corrupting metadata.
Hide
Permalink
Brett Porter added a comment -

its not "corrupt". Its written as default, which is no versions. It doesn't try again for another day.

1) its not empty, its just written out with defaults. This should be stopped so that it tries again.

2) it won't corrupt the local data, they are in separate files.

It's not about care when downloading, it just needs to avoid writing out files when there was a failure. BUT - be careful when changing this, if you take out the writing of the file when it is not found in the remote repo, it will check every single build.

Show
Brett Porter added a comment - its not "corrupt". Its written as default, which is no versions. It doesn't try again for another day. 1) its not empty, its just written out with defaults. This should be stopped so that it tries again. 2) it won't corrupt the local data, they are in separate files. It's not about care when downloading, it just needs to avoid writing out files when there was a failure. BUT - be careful when changing this, if you take out the writing of the file when it is not found in the remote repo, it will check every single build.
Hide
Permalink
John Casey added a comment -

I updated the behavior on TransferFailedException only, so when the resource simply 404's on the remote side, it should still be fine.

Show
John Casey added a comment - I updated the behavior on TransferFailedException only, so when the resource simply 404's on the remote side, it should still be fine.
Hide
Permalink
John Casey added a comment -

this turns out to be a simple fix, where it's just a matter of changing the behavior of the DefaultRepositoryMetadataManager's private resolveAlways(..) method for cases where it catches a TransferFailedException.

Show
John Casey added a comment - this turns out to be a simple fix, where it's just a matter of changing the behavior of the DefaultRepositoryMetadataManager's private resolveAlways(..) method for cases where it catches a TransferFailedException.
Hide
Permalink
John Casey added a comment -

the private resolveAlways(..) method throws TransferFailedException after blacklisting the repository. When caught in the resolve(..) method, this inhibits writing the empty metadata to the local repo. In other methods, this exception is thrown away, as logging has been done in the resolveAlways(..) method. HOWEVER, these cases have been marked TODO, so we can revisit this behavior for 2.1 if necessary.

Show
John Casey added a comment - the private resolveAlways(..) method throws TransferFailedException after blacklisting the repository. When caught in the resolve(..) method, this inhibits writing the empty metadata to the local repo. In other methods, this exception is thrown away, as logging has been done in the resolveAlways(..) method. HOWEVER, these cases have been marked TODO, so we can revisit this behavior for 2.1 if necessary.
Hide
Permalink
Kenney Westerhof added a comment -

The handling for the 404 deletes the file from the local repository.

My fix for MNG-2712 extends the behaviour a bit: if there's a transferfailed,
and the file does not already exist, then an empty metadata file (with defaults)
is written, to mark the error timestamp. This way, on consecutive builds,
the repo isn't checked again numerous times.

This is because wagon doesn't always throw a ResourceDoesNotExistException
if there's a 404, it sometimes also throws it's superclass. Now errors are
marked, and the next day (or on force), an attempt is made to retrieve the metata
again.

Show
Kenney Westerhof added a comment - The handling for the 404 deletes the file from the local repository. My fix for MNG-2712 extends the behaviour a bit: if there's a transferfailed, and the file does not already exist, then an empty metadata file (with defaults) is written, to mark the error timestamp. This way, on consecutive builds, the repo isn't checked again numerous times. This is because wagon doesn't always throw a ResourceDoesNotExistException if there's a 404, it sometimes also throws it's superclass. Now errors are marked, and the next day (or on force), an attempt is made to retrieve the metata again.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
1h
Original Estimate - 1 hour
Remaining:
0m
Remaining Estimate - 0 minutes
Logged:
1h
Time Spent - 1 hour
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.