[GRADLE-2869] Maven plugin fails to resolve `${user.home}` in settings.xml, hence gets local Maven repo location wrong on `install` Created: 14/Aug/13  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Gradle Forums Assignee: Unassigned
Resolution: Won't Fix Votes: 3


The Maven plugin fails the install task with the following message:

Execution failed for task ':install'.
> Could not publish configuration 'archives'
> Error installing artifact 'lucene-learning:common:jar': Error installing artifact: /Repositories/maven/lucene-learning/common/1.0/common-1.0.jar (No such file or directory)

The path it is trying to go to does not exist. Apparently, it is ignoring the local repo in my settings.xml. It is also ignoring the following which I've put in the build file, though I shouldn't need to.

uploadArchives {
repositories {
mavenDeployer {
repository(url: "file://Users/Abhijit/Repositories/maven")

Comment by Gradle Forums [ 14/Aug/13 ]

For the `install` task, you'll have to configure `mavenInstaller` rather than `mavenDeployer`. A local repo location specified in `~/.m2/settings.xml` (not `settings.xml` in the Maven install dir) will be honored. I'm not entirely sure what the error message is complaining about; a full stack trace (as a Github Gist) might help.

Comment by Gradle Forums [ 14/Aug/13 ]

As I said, a `mavenDeployer` repo declaration will only affect `upload` but not `install`. System properties in the local repo location used to be supported, but may not be supported anymore.

Comment by Gradle Forums [ 14/Aug/13 ]

Sorry, I deleted my comment and wanted to add that to the original post instead. However, you'd posted in the meantime so original post couldn't be edited. Adding my comment back again so that people visiting this thread know what the issue is.

I turns out that the settings.xml defines localRepository as below:


This is perfectly valid for Maven. However, Gradle couldn't resolve ${user.home} variable and was ignoring that.

Comment by Gradle Forums [ 14/Aug/13 ]

Peter, can you please provide a sample code of how to configure the mavenInstaller? Also, other tasks are resolving user.home just fine, why wouldn't install task?

Comment by Gradle Forums [ 14/Aug/13 ]

Just use `mavenInstaller` instead of `mavenDeployer`. Not sure what you mean by "other tasks are resolving user.home fine". It's about supporting the Maven expression language used in pom.xml and settings.xml.

Comment by Gradle Forums [ 14/Aug/13 ]

This fails so apparently it's slightly more involved than just replacing mavenDeployer with mavenInstaller. The Maven plugin page doesn't have any indication of how to configure a mavenInstaller.

install {
repositories {
mavenInstaller {
repository(url: "file:///Users/Abhijit/Repositories/maven")

  • What went wrong:
    A problem occurred evaluating root project 'common'.
    > Could not find method repository() for arguments [ {url=file:///Users/Abhijit/Repositories/maven}

    ] on repository container.

Comment by Gradle Forums [ 14/Aug/13 ]

What I meant by "other tasks are resolving user.home" is that Maven plugin in general does not have a problem finding the local repo and downloading from it. It's only the install task that fails.

Comment by Gradle Forums [ 14/Aug/13 ]

The book "Building and Testing with Gradle" states in chapter 4, section "Installing to the Local Maven Repository" that "This install process, equivalent to mvn install, is *guaranteed* to be compatible with Maven because it actually uses the Maven Ant Tasks produced by the Maven team and hosted at Apache.".

If this is not a contradiction, I don't know what is.

Comment by Gradle Forums [ 14/Aug/13 ]

maven-publish plugin handles ${user.home} variable just fine, why can't the maven plugin do that? This should be a bug.

Comment by Gradle Forums [ 14/Aug/13 ]

Can we have a JIRA on this please?

Comment by Gradle Forums [ 14/Aug/13 ]

It's a limitation or, if you will, bug. Not more, not less.

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 12:33:40 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.