mavenLocal broken when <localRepository/> found in Maven settings.xml

[pkubowicz]

Regression in 3.5 compared to 3.4.1 - mavenLocal() does not work

Expected Behavior

• you can read plugins from mavenLocal()
• you can read dependencies from mavenLocal()
• you can publish to mavenLocal()

Current Behavior

• publishing to mavenLocal() publishes to the current directory
• plugins from mavenLocal() are not seen
• dependencies from mavenLocal() are not seen

Gradle 3.5 treats the current directory as the local Maven repo:

Could not resolve all dependencies for configuration ':app:compileClasspath'.
> Could not find com.example:plugin:0.1-SNAPSHOT.
  Searched in the following locations:
      file:/home/pkubowicz/devel/bugs/gradle-maven-local/app/com/example/plugin/0.1-SNAPSHOT/maven-metadata.xml
      file:/home/pkubowicz/devel/bugs/gradle-maven-local/app/com/example/plugin/0.1-SNAPSHOT/plugin-0.1-SNAPSHOT.pom
      file:/home/pkubowicz/devel/bugs/gradle-maven-local/app/com/example/plugin/0.1-SNAPSHOT/plugin-0.1-SNAPSHOT.jar

Context

IMO this bugs breaks the basic developer lifecycle

Steps to Reproduce (for bugs)

Follow instructions in https://github.com/pkubowicz/gradle-maven-local

Your Environment

Linux, Gradle 3.5

• Build scan URL: https://scans.gradle.com/s/g3xdotd75r4x2

[bmuschko]

@pkubowicz Your plugin subproject does not contain any code - no class that implements Plugin nor a plugin descriptor. An oversight? Can you please add it to your repository?

Also if I modify your build script slightly by adding a group e.g. group = 'com.example' I definitely see the artifact being published to Maven Local when running gradle plugin:publishToMavenLocal.

$ tree /Users/bmuschko/.m2/repository/com/example
/Users/bmuschko/.m2/repository/com/example
└── plugin
    ├── 0.1-SNAPSHOT
    │   ├── maven-metadata-local.xml
    │   ├── plugin-0.1-SNAPSHOT.jar
    │   └── plugin-0.1-SNAPSHOT.pom
    └── maven-metadata-local.xml

[pkubowicz]

It should not matter if the plugin contains any code. I found this bug on a bigger project, but I don't want to share it, so I prepared a minimal fake project demonstrating the issue. To avoid any confusion, I have just added a single class to plugin directory.

Note that:

1. I have subprojects { group = 'com.example' } in the root project, so there is no reason to add group='com.example' to plugin/build.gradle
2. This works correctly in Gradle 3.4, so it should not matter whether the JAR is empty or not.
3. It does not matter whether the class is present or not, the problem is why is the current directory treated as the local Maven repo.
4. It is not a bug just in publishing plugin. If I put the JAR to local Maven using Gradle 3.4, Gradle 3.5 is not able to read it (gradle app:classes does not work). Again, see the report: the current directory is searched instead of ~/.m2

[bmuschko]

I have subprojects { group = 'com.example' } in the root project, so there is no reason to add group='com.example' to plugin/build.gradle

Sorry, I didn't look in the root project. That's fine then.

Are you running your project in parallel? I don't think the publishing/consuming logic itself is the problem. It's more a problem with execution order.

1. If I run gradle plugin:publishToMavenLocal I see the published artifact in Maven Local.
2. If I run gradle build then the project builds correctly without issues.
3. If I run gradle plugin:publishToMavenLocal build with org.gradle.parallel=true then I see the issue you report. I think app:compileJava simply happens before plugin:publishToMavenLocal because the projects are executed in parallel.

Can you verify the same behavior?

[pkubowicz]

No, I don't run in parallel. You can confirm it in my build scan.

I am suprised that you can put anything to ~/.m2. My build prints (I added additional logging):

~/devel/bugs/gradle-maven-local% ls
app  build.gradle  plugin  README.md  settings.gradle
% gradle plugin:publishToMavenLocal
$HOME is /home/pkubowicz
:plugin:generatePomFileForFooPluginPluginMarkerMavenPublication
:plugin:publishFooPluginPluginMarkerMavenPublicationToMavenLocal
:plugin:generatePomFileForPluginMavenPublication
:plugin:compileJava UP-TO-DATE
:plugin:pluginDescriptors UP-TO-DATE
:plugin:processResources UP-TO-DATE
:plugin:classes UP-TO-DATE
:plugin:jar UP-TO-DATE
:plugin:publishPluginMavenPublicationToMavenLocal
:plugin:publishToMavenLocal
:plugin:showMavenLocal
ls: cannot access '/home/pkubowicz/.m2/repository/com/example': No such file or directory

BUILD SUCCESSFUL
% ls  
app  build.gradle  com  fooPlugin  plugin  README.md  settings.gradle

[bmuschko]

Do you have a settings.xml that changes the default Maven Local directory?

[pkubowicz]

You are right: if I remove ~/.m2/settings.xml the problem disappears.

I removed credentials from this file, then reduced it to the minimal template from the Maven website and it still triggers bad behaviour of Gradle 3.5:

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                          https://maven.apache.org/xsd/settings-1.0.0.xsd">
    <localRepository/>
    <interactiveMode/>
    <usePluginRegistry/>
    <offline/>
    <pluginGroups/>
    <servers/>
    <mirrors/>
    <proxies/>
    <profiles/>
    <activeProfiles/>
</settings>

[bmuschko]

It looks like this is a regression in the way we handle <localRepository/>. It seems to evaluate to the current directory instead of the default value ${user.home}/.m2/repository. As a workaround you can just remove the empty tag or set it to an actual value of your choice.

[bigdaz]

Thanks for the report @pkubowicz: I'm working on a fix.

[bigdaz]

Pending a fix, another workaround would be to set the maven.repo.local system property for your build.

[asarkar]

We are impacted by this issue too. Why is this ticket closed? Shouldn't it be kept open until a fix is released and the reporter has a chance to verify it?

[bmuschko]

@asarkar The reporter and you can try out the fix with one of our nightly builds: https://gradle.org/nightly. Keep in mind that we already branched for 4.0 and that's why you see 4.1 here. We currently do not produce nightlies for releases we are in the process of finishing up. Certainly something we could improve on.

Either way we close the ticket when we think it is fixed to keep track of it. We write plenty of tests so we are pretty confident that it is fixed. Feel free to try a nightly.

[asarkar]

@bmuschko The nightly build is Dev build, and there's no guarantee what works today, will continue to work in the final release. APIs may be changed (not unusual until RC), or simply a regression may show up (like the one being discussed here). Closing a ticket based on nightly build is unreliable, and doesn't help the user.

[bmuschko]

@asarkar We are heavily relying on different types of tests. In one form we are actually building a new distribution of Gradle for the latest commit and run the tests with that distribution. The change also contains these types of tests. If code has been changed in that area then the tests should break as well. If the tests don't break then we did a bad job. So far I can't really remember many occasions when we didn't write the appropriate tests and the functionality was still broken. So you'll have to trust us to do the right thing. Feel free to manually test the RC. It's going to come up soon.

[pp-lucaal-sportsbet]

This is still happening for me even with the localRepository tag correctly set!