Error with "gradle init"

(davidmichaelkarr) #1

I’m getting back into Gradle usage this morning, after being an observer for a while.

I’m implementing a Gradle build for an existing application with a Maven build, as I’ve realized the Maven build just can’t do something I need to do.

The application is an Eclipse plugin, which is a domain I’m very new to.

I decided to try “gradle init” just to see what it does. In my previous experience, I considered using “init” a worthwhile step, although it often would fail to complete. That is also the case here, and I’d just like to explore this a bit.

The stacktrace I get is the following (this is just the lowest root cause):
` Caused by: java.lang.NullPointerException
at org.sonatype.aether.impl.internal.DefaultMetadataResolver.resolve(
at org.sonatype.aether.impl.internal.DefaultMetadataResolver.resolveMetadata(
at org.apache.maven.repository.internal.DefaultVersionResolver.resolveVersion(
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(
at org.sonatype.aether.impl.internal.DefaultRepositorySystem.resolveArtifact(
at org.apache.maven.project.ProjectModelResolver.resolveModel(
at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(
at org.apache.maven.model.building.DefaultModelBuilder.readParent(
at org.gradle.buildinit.plugins.internal.maven.MavenProjectsCreator.createNow(
at org.gradle.buildinit.plugins.internal.maven.MavenProjectsCreator.create(

`I tried opening “DefaultMetadataResolver” in Eclipse and looking at line 279, and I see that it’s not an executable line (I’m seeing the jd-eclipse decompiled output, but it’s usually pretty good at keeping line number correspondence). That tells me that the version of the jar file I’m seeing in Eclipse is not the same as what Gradle is using. In Eclipse, this class file appears to be in “aether-impl-1.0.2.v20150114.jar”. Is there an easy way to tell what version Gradle is using?

(René Groeschke) #2

It depends on the Gradle version you’re using. The latest Gradle should come with aether-impl-1.13.1. The pom conversion functionality has some limitations. Can you provide a small reproducible example of the problem you’re facing?


(Victor Volle) #3

I debugged this for half a day now: getLocalRepository() is null.
This is triggered when

  • I have repositories in pom (without them: no problem)
  • relative paths (not totally sure, but all existing other projects are okay)

Even after some hours I do not understand who should set the “local repository” in the session and how it should be done:

  File checkFile =
    new File(
             session.getLocalRepository().getBasedir(), // NPE HERE
             session.getLocalRepositoryManager().getPathForRemoteMetadata( metadata, repository,
                                                                           request.getRequestContext() ) );

(Victor Volle) #4

This fixes the problem for me. Unluckily I have not been able to create a stripped down test case. So please review carefully:

diff --git a/subprojects/build-init/src/main/groovy/org/gradle/buildinit/plugins/internal/maven/ b/subprojects/build-init/src/main/groovy/org/gradle/buildinit/plugins/internal/maven/
index 7a85812..687da30 100644
--- a/subprojects/build-init/src/main/groovy/org/gradle/buildinit/plugins/internal/maven/
+++ b/subprojects/build-init/src/main/groovy/org/gradle/buildinit/plugins/internal/maven/
@@ -30,6 +30,7 @@ import org.codehaus.plexus.classworlds.ClassWorld;
 import org.codehaus.plexus.component.repository.exception.ComponentLookupException;
 import org.codehaus.plexus.configuration.PlexusConfigurationException;
 import org.sonatype.aether.RepositorySystemSession;
+import org.sonatype.aether.impl.internal.EnhancedLocalRepositoryManager;
 import org.sonatype.aether.util.DefaultRepositorySystemSession;
 import org.gradle.util.CollectionUtils;

@@ -68,6 +69,12 @@ public class MavenProjectsCreator {
         ProjectBuildingRequest buildingRequest = executionRequest.getProjectBuildingRequest();
+        DefaultRepositorySystemSession sx = new DefaultRepositorySystemSession();
+        EnhancedLocalRepositoryManager lm = new EnhancedLocalRepositoryManager(new File(buildingRequest.getLocalRepository().getBasedir()));
+        sx.setLocalRepositoryManager(lm);
+        buildingRequest.setRepositorySession(sx);
         MavenProject mavenProject =, buildingRequest).getProject();
         Set<MavenProject> reactorProjects = new LinkedHashSet<MavenProject>();

@@ -75,6 +82,7 @@ public class MavenProjectsCreator {
         //the converter should not depend on the order of reactor projects.
         //we should add coverage for nested multi-project builds with multiple parents.
         List<ProjectBuildingResult> allProjects =, true, buildingRequest);
         CollectionUtils.collect(allProjects, reactorProjects, new Transformer<MavenProject, ProjectBuildingResult>() {
             public MavenProject transform(ProjectBuildingResult original) { 

the basic issue is that some inner class does not return a LocalRepository – which I suspect is a bug in “aether”, but the above patch takes care of that.
All tests with gradle test are “green” but since I do not completely understand “aether”, I am not sure what this might break. Would love to see some more testing from other developers

(Victor Volle) #5

patch can be found here:

(René Groeschke) #6

Hey Victor,

thanks for all the effort you put into this. Would you mind raising a pull request for this on github?


(Victor Volle) #7

Give me until next Monday, I really would like to understand what should be done.
My fix “works for me” but that is all.
I just started to debug the same project using Maven and the buildRequest is initialised in a different way (local repository is null and the session is created differently). I would very much prefer to have a version that works more like Maven itself – but the Aether documentation is nearly non-existent (only JavaDoc).

(René Groeschke) #8


there is really no need to rush. Take the time you need. I know the pain about the aether documentation :wink:

looking forward to your contribution.

cheers, rene