[GRADLE-2008] Make tooling api results consistent with cli Created: 20/Dec/11  Updated: 04/Jan/13  Resolved: 27/Jan/12

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

Type: Bug
Reporter: Denis Zhdanov Assignee: Unassigned
Resolution: Not A Bug Votes: 0


 Description   

Consider the following simple project:

repositories {
    mavenCentral()
}
 
configurations {
    compile
    runtime
}
 
dependencies {
    compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
}

CLI shows the following:

denis@unit-240:~/Downloads$ gradle -v; gradle dependencies

------------------------------------------------------------
Gradle 1.0-milestone-7-20111219065105+0100
------------------------------------------------------------

Gradle build time: Monday, December 19, 2011 5:51:05 AM UTC
Groovy: 1.8.4
Ant: Apache Ant(TM) version 1.8.2 compiled on December 20 2010
Ivy: 2.2.0
JVM: 1.6.0_26 (Sun Microsystems Inc. 20.1-b02)
OS: Linux 2.6.38-10-generic amd64

:dependencies

------------------------------------------------------------
Root project
------------------------------------------------------------

compile
\--- org.hibernate:hibernate-core:3.6.7.Final [default]
     +--- antlr:antlr:2.7.6 [compile,master,runtime]
     +--- commons-collections:commons-collections:3.1 [compile,master,runtime]
     +--- dom4j:dom4j:1.6.1 [compile,master,runtime]
     +--- org.hibernate:hibernate-commons-annotations:3.2.0.Final [compile,master,runtime]
     |    \--- org.slf4j:slf4j-api:1.6.1 [compile,master,runtime]
     +--- org.hibernate.javax.persistence:hibernate-jpa-2.0-api:1.0.1.Final [compile,master,runtime]
     +--- javax.transaction:jta:1.1 [compile,master,runtime]
     \--- org.slf4j:slf4j-api:1.6.1 [compile,master,runtime] (*)

runtime
No dependencies

(*) - dependencies omitted (listed previously)

BUILD SUCCESSFUL

Total time: 2.098 secs

However, tooling api doesn't expose the dependencies for the same build file:

import org.gradle.tooling.GradleConnector;
import org.gradle.tooling.ModelBuilder;
import org.gradle.tooling.ProjectConnection;
import org.gradle.tooling.model.idea.*;

import java.io.File;

/**
 * @author Denis Zhdanov
 * @since 12/8/11 5:07 PM
 */
public class GradleStartClass {

  private static final String GRADLE_TO_USE = "/home/denis/dev/gradle/gradle-1.0-milestone-7-20111219065105+0100";
  private static final String GRADLE_PROJECT_PATH = "/home/denis/Downloads";

  public static void main(String[] args) {
    showDependencies();
  }

  private static void showDependencies() {
    GradleConnector connector = GradleConnector.newConnector();
    connector.useInstallation(new File(GRADLE_TO_USE));
    connector.forProjectDirectory(new File(GRADLE_PROJECT_PATH));
    ProjectConnection connection = connector.connect();
    ModelBuilder<? extends IdeaProject> modelBuilder = connection.model(IdeaProject.class);
    IdeaProject project = modelBuilder.get();
    System.out.println("-----------------> Listing dependencies <----------------");
    for (IdeaModule module : project.getModules()) {
      for (IdeaDependency dependency : module.getDependencies()) {
        System.out.println(dependency);
      }
    }
    System.out.println("-----------------> Listing complete <----------------");
  }
}

Output

-----------------> Listing dependencies <----------------
-----------------> Listing complete <----------------


 Comments   
Comment by Denis Zhdanov [ 12/Jan/12 ]

Please have a look at the another use-case that mentions different dependencies processing by cli and the tooling api - http://devnet.jetbrains.net/message/5448659

Comment by Szczepan Faber [ 16/Jan/12 ]

This is expected behavior. If you don't apply java plugin, your gradle project does not have a concept of runtime / compile configurations, e.g. those are just names. When you do apply the java plugin then 'compile' and 'runtime' (and others) dependencies mean stuff that needs to be on the classpath. Gradle understands that and places it in the generated *.iml or in the tooling api results.

Consider this:

apply plugin: 'java'

repositories {
    mavenCentral()
}
 
configurations {
    foo
    bar
}
 
dependencies {
    compile group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
    foo group: 'org.hibernate', name: 'hibernate-core', version: '3.6.7.Final'
}

When you run 'gradle dependencies' gradle resolves all deps and shows them, so it will include dependencies for foo, bar, compile, testCompile, ...

When you run 'gradle idea' or use the tooling api to get the IdeaProject they will only contain compile/testCompile/runtime deps.

Hope it makes sense as it's quite late

Comment by Denis Zhdanov [ 16/Jan/12 ]

Am I right understanding that the tooling api is bound to the 'java' project here? What if we have not 'java' but, say, 'groovy' plugin enabled? Are the dependencies expected to be shown by the tooling api then?

Comment by Szczepan Faber [ 26/Jan/12 ]

groovy/scala plugin apply java plugin behind the hood so it should all good.

Tooling Api is not bound to the java nature of the project. However, the jar dependencies, classpath, source and test compilation units, etc, all that make only sense if the java-related plugin is applied. So if you ask tooling api to provide Idea model of the non-java project you'll get a project, modules but not dependencies, source trees, etc.

Comment by Denis Zhdanov [ 27/Jan/12 ]

Ok, thanks for the info

Comment by Szczepan Faber [ 27/Jan/12 ]

I'm inclined to resolve this issue as this is not really a bug.

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