[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?

[jira-importer]

Dennis Lundberg commented

@Karl-Heinz, In my case yes. The Jenkins jobs all share the same local repository.

[jira-importer]

Karl Heinz Marbaise commented

Hm...I would say it's not wise to share a common local repository from two Jenkins jobs which makes them in consequence no longer independent. Furthermore as far as i know is Maven not designed to handle concurrent access to the same local repository...May be i miss a thing here...

[jira-importer]

Gareth Daniel Smith commented

Same issue is affecting me - multiple concurrent builds on a Bamboo build server. IMHO Maven should really handle this use-case, because it is very common.

[jira-importer]

Jonathan Woods commented

We're running Maven builds on Jenkins slave instances, and to avoid clashes of the kind described in this ticket we're using

<localRepository>${user.home}/.m2/repository/${env.EXECUTOR_NUMBER}</localRepository>

in the operative settings.xml file for Maven invocations. This means there's a Maven artifact cache per Jenkins executor, and so no opportunity for clashes. Not quite as good as a slave-wide (or Jenkins-wide) Maven cache, but plenty good enough for us.

[jira-importer]

Dan Armbrust commented

Whenever someone mentions maven, and I curse under my breath, this bug report is now the most recent example of everything that is wrong with this project.

We have a dumb bug, identified 8 years ago. 

A patch is provided years and years ago.

And the maintainers can't even be bothered to apply it.

Now that I have switched over to using pipeline builds with jenkins - when i do a release, it ends up building both master and development branches at the same time.

Guess what happens when a build server tries to do two builds at the same time... good lord.

What the heck is the point of having a local cache, if you can't use it in parallel?  This should be part of the basic requirements.....

The point of the cache is to save me from GB and GB of downloads.  If I have to use a per-build cache, or reconfigure jenkins to have a per-instance cache, I'm wasting disk, bandwidth, slowing down all my builds, and making it impossible to build dependent code without having an artifact server running, since I can't rely on a mvn install from one instance making the latests snapshot code available to another instance.

 

What is it going to take to get this fixed?

Does someone need to remote in to a maintainers computer, and type the keystrokes for them to do the merge?

Of course, at this point, since they ignored a patch that was supplied to them, I'm sure it will no longer apply cleanly.

 

[jira-importer]

Dan Armbrust commented

I have run across this, in researching this issue - will be testing it out myself: http://takari.io/book/30-team-maven.html#concurrent-safe-local-repository

No idea why this code has to be outside of core maven:  https://github.com/takari/takari-local-repository

rather than just being merged into maven, to fix the problem for everyone....

[jira-importer]

Tibor Digana commented

Geoff Simpson If you often see this issue and you have multithreaded build system, it means you have the problem of design because you have a common local repo. In my experiences this has nevere happened because every run of job in Jenkins was designed in Groovy Jenkinsfile in the way that local repositories were isolated in each run. Therefore no shared artifacts across builds and jobs, which is the best practice. I don't think the file locking is the way still because shared artifacts of jobs and builds override artifacts of your current job by foreign job and the build shows you fake result.

[jira-importer]

Rocco De Angelis commented

tibordigana

I don't get it. I run a multithreaded build on my local machine and no other maven process or build is running. So I don't understand how this issue can happen. It seems that one maven build thread tries to install an artifact (updating a maven-meta.xml) during another build thread tries to resolve the module dependencies and tries to read exactly the same maven-meta.xml file?

[jira-importer]

Alan Czajkowski commented

Geoff Simpson tibordigana Rocco De Angelis It appears that Jonathan Woods has the most reasonable solution to this problem: by adding this to the build server's Maven settings.xml file:

<localRepository>${user.home}/.m2/repository-${env.EXECUTOR_NUMBER}/</localRepository>

This solution is specific to Jenkins, but can be ported to any other build system.

You can't use a global cache because of the concurrent access (read & write) conflict. You don't want to use a Maven local cache per build because the performance of trying to download "the entire world" on every build would be too painful. So, the reasonable thing to do is the compromise: set the cache to be executor-specific that way you get a semi-global cache, but don't need to download the entire world every time, and you get the safety of the executor only being able to run sequentially (solving the concurrency problem).

[jira-importer]

Elliotte Rusty Harold commented

Hasn't been reported for a while. Is this still happening?

[jira-importer]

Mazie Britt commented

Elliotte Rusty Harold

Yes it's still happening on my end when running two mvn install instances in parallel. Latest maven 3.6.3.

[jira-importer]

Gjøran Voldengen commented

Like Rocco De Angelis reports above, we also see this on a single multi-threaded maven build. This particular build is for a list of maven plugins, and it seems that each thread building a plugin tries to update the maven-metadata.xml file of the group it belongs to. If this is the case, a possible (but inconvenient) workaround could be to use a separate groupId for each plugin.

Our project is open source, and the pom.xml file can be found here: https://github.com/vespa-engine/vespa/blob/master/maven-plugins/pom.xml

Maven version: 3.6.3

maven-install-plugin:2.5.2

[jira-importer]

Roman Zabaluev commented

Can confirm that this issue is still a thing. We encounter such a problem running maven 3.x on Atlassian bamboo. Few parallel builds for the same projects are writing branch names to that file and it gets corrupted. We have to clean it up at least few times a day and rebuild the branch which takes 20-60+ minutes.

Is there any chance that this issue will ever get fixed? 

[jira-importer]

Daniel Huss commented

tibordigana

it means you have the problem of design because you have a common local repo. 

Therefore no shared artifacts across builds and jobs, which is the best practice.

There you have it, people! Your expectation that a user-local repository can be accessed by concurrent builds is stupid and wrong!

Better follow BEST PRACTICES kindly provided by the superior minds at work here, and have your K8S agent download those 10GB of JARs from Nexus on every build! Only takes Maven 15 minutes to complete on a GBIT wire!