[MINSTALL-54] [INFO] Error installing artifact's metadata

[jira-importer]

Geoff Simpson opened MINSTALL-54 and commented

[INFO] 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

---

Affects: 2.2

Attachments:

• minstall-54-error-install-artifact.patch (6.56 kB)

Issue Links:

• MINVOKER-104 Error installing artifact's metadata

• MNG-5307 NPE during resolution of dependencies - parallel mode

15 votes, 25 watchers

[jira-importer]

Dennis Lundberg commented

Do you have an example project that we can use to verify this issue?
It would also be good is you could supply more information about your environment, like Java version, Maven version etc.

[jira-importer]

Erik Husby commented

I've just started seeing this same problem. I am running Maven builds from the Bamboo build server on a faster machine than I was on and am running multiple builds simultaneously.

[jira-importer]

Klaus Wienert commented

We have the same Problem, using Continuum doing 'mvn deploy' simultaneously to the developers.

[jira-importer]

Edd Steel commented

Same problem with simultaneous installs of a common parent library or pom on hudson.

Java 1.5.0_15
Maven 2.1.0
Maven Install Plugin 2.2

[jira-importer]

Daniele commented

I received this error as well, not on my machine, just on the machine where runs Hudson.
I manage to make it back to work removing the maven-metadata-local.xml in the folder
/home/boxo-proto/.m2/repository/net/phaedra/phaedra-commons/0.6.2/

Both my machine and CI server run with ubuntu 9.10, sun JDK 6.

here was the output:

[INFO] [jar:jar {execution: default-jar}]
[INFO] [install:install {execution: default-install}]
[INFO] Installing /home/boxo-proto/.hudson/jobs/phaedra/workspace/phaedra/phaedra-commons/target/phaedra-commons-0.6.2.jar to /home/boxo-proto/.m2/repository/net/phaedra/phaedra-commons/0.6.2/phaedra-commons-0.6.2.jar
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata

input contained no data
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata

Here the complete stack trace:

org.apache.maven.lifecycle.LifecycleExecutionException: Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:719)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
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:597)
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.MojoExecutionException: Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata
at org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:143)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:490)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
... 17 more
Caused by: org.apache.maven.artifact.installer.ArtifactInstallationException: Error installing artifact's metadata: Error installing metadata: Error updating group repository metadata
at org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:123)
at org.apache.maven.plugin.install.InstallMojo.execute(InstallMojo.java:105)
... 19 more
Caused by: org.apache.maven.artifact.repository.metadata.RepositoryMetadataInstallationException: Error installing metadata: Error updating group repository metadata
at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.install(DefaultRepositoryMetadataManager.java:462)
at org.apache.maven.artifact.installer.DefaultArtifactInstaller.install(DefaultArtifactInstaller.java:111)
... 20 more
Caused by: org.apache.maven.artifact.repository.metadata.RepositoryMetadataStoreException: Error updating group repository metadata
at org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository(AbstractRepositoryMetadata.java:72)
at org.apache.maven.artifact.repository.metadata.DefaultRepositoryMetadataManager.install(DefaultRepositoryMetadataManager.java:458)
... 21 more
Caused by: java.io.EOFException: input contained no data
at hidden.org.codehaus.plexus.util.xml.pull.MXParser.fillBuf(MXParser.java:3005)
at hidden.org.codehaus.plexus.util.xml.pull.MXParser.more(MXParser.java:3048)
at hidden.org.codehaus.plexus.util.xml.pull.MXParser.parseProlog(MXParser.java:1422)
at hidden.org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1407)
at hidden.org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1105)
at org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader.read(MetadataXpp3Reader.java:949)
at org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata(AbstractRepositoryMetadata.java:98)
at org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository(AbstractRepositoryMetadata.java:68)
... 22 more

[jira-importer]

Daniel Takai commented

We're experiencing the same problem. We run

• Archiva 1.2.1
• CentOS release 5 (Final)
• Java 1.6.0_02
• Maven 2.2.1

[INFO] Retrieving previous metadata from snapshots 
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Error installing artifact's metadata: 
       Error installing metadata: 
       Error updating group repository metadata in epilog 
       non whitespace content is not allowed but got n 
       (position: END_TAG seen ...</metadata>\nn... @14:2) 
[INFO] ------------------------------------------------------------------------

This problem occurs on a regular basis (daily) and causes problems with our builds since artifacts cannot be deployed and builds fail. The corrupt metadata needs to be repaired manually which is quite a lot of work. Quite nerve wrecking when you really need that build and Archiva goes booooom.

An example for corrupt metadata look like this:

<metadata>
  <groupId>com.some.group</groupId>
  <artifactId>html</artifactId>
  <versioning>
    <latest>0.1-SNAPSHOT</latest>
    <versions>
      <version>0.1-SNAPSHOT</version>
    </versions>
    <lastUpdated>20100202145220</lastUpdated>
  </versioning>
</metadata>
>html</artifactId>
  <versioning>
    <latest>0.1-SNAPSHOT</latest>
    <versions>
      <version>0.1-SNAPSHOT</version>
    </versions>
    <lastUpdated>20100202163215</lastUpdated>
  </versioning>
</metadata>

[jira-importer]

Daniel Takai commented

I forgot to mention: Our environment is not multi threaded for artifact updates.

[jira-importer]

Thomas Aanensen commented

Also affects maven-install-plugin version 2.3

[jira-importer]

Michael Wenig commented

A similar problem did occur right now at our site

Using maven 22.1, Hudson 1.397 on a 8-core Linux-VM during release of one project.

Previously we had fixed down the use of mave-parent:0.12 (with install-plugin:2.2/invoker:1.2) via a dependcy-declaration.

We removed the maven-parent-version-lock (which was there for some unknown reasons) and the error suddenly occured (now install:2.3 and invoker:1.5) are used.

Is the patch of Geoff planned to be integrated?

[jira-importer]

djohnament commented

Ping. any chance this can get merged in to Maven3?

[jira-importer]

Robert Scholte commented

I'm actually more curious to the real cause of this issue. It seems like at the same time 2 installments of the same artifact is done. Isn't that kind of weird? For instance, with Jenkins, if a job is called multiple times, only one will be executed and the rest will be waiting in the queue.
In most cases there's no need to do an install. Especially on buildserver, I'd run clean verify and let the build-server upload the artifacts to a repositorymanager. This way you are completely sure that other builds/developers can and will use the artifact as served by the repository manager (what is deploy fails?). If your buildserver has no such option, then run mvn clean deploy -Dmaven.install.skip
Next, synchronization and IO are quite expensive, so this should be avoided as much as possible. So the default behavior should stay as it is.
Now, the fact that the meta-data can get corrupt does mean that something needs to be fixed. When calling install, the files are passed to Maven-core, which is responsible for the actual copy to the local repository. So that's probably the best place where something needs to be fixed.

[jira-importer]

djohnament commented

In my case, it's actually the maven-metadata-local.xml in the artifact's directory (not the artifact-version). So we have multiple builds going on concurrently across different product versions (because everything builds at ungodly hour o'clock in the night).

[jira-importer]

Dennis Lundberg commented

There seems to be a connection between MNG-5307 and MINSTALL-54. Reading through all the comments in both issues, and experiencing the issues myself, here are my conclusions.

In MNG-5307 people are running Maven in multi threaded mode. In this issue people are running Maven without multi threading, but on a build server. Going through the logs on our build server (Jenkins) made me realize that we are running several builds of the same code using a @daily schedule. There are several builds because they use different combinations of Maven and Java.

So there seems to be a problem when several processes are concurrently modifying the meta data files. Either using multiple threads in Maven or running multiple jobs on a build server. I don't know if the problem is in the Install Plugin or Maven Core though.

[jira-importer]

Sam Hendley commented

Are there any workarounds or any way to disable to this behavior? This issue is still biting us on 3.04 when we try to run multiple maven jobs at same time that are producing different versions of the same artifacts.

[jira-importer]

Karl Heinz Marbaise commented

Does that mean you are using the same local repository from independant jenkins jobs?