I have a question about how the Gradle Eclipse plugin fails to generate Java Build Path "Source" folder entries


(Jon Austen) #1

I have a question about how the Gradle Eclipse plugin fails to generate Java Build Path “Source” folder entries.

I have been playing around with this plugin but can’t seem to figure out the use of it.

I have a multi-project Gradle build, that is laid out like so:

root/
  subprojects/
    ---- core/
(utilities)
    ---- proj1/
    ---- proj2/
    ---- etc.

But, when I include the ‘eclipse’ plugin and run the ‘eclipse’ build task, the .project file and .classpath file that is generated does not include the proper source configuration to enable intellisense to work.

Am I overlooking something here or is this a limitation of this plugin?

I was expecting the generated files to somehow configure the eclipse project to include ‘src’ folders for my multiple projects by reading the ‘settings.gradle’ file and computing paths to my sub-projects for Eclipse.

If I am misunderstanding this, is there any more information available anywhere besides the limited information in the documentation (http://gradle.org/docs/current/dsl/org.gradle.plugins.ide.eclipse.model.EclipseProject.html) ?

Now, when I examine the .classpath file for one of my sub-projects, I see the following contents are included:

<classpathentry kind="src" path="src/main/java"/>
 <classpathentry kind="src" path="src/test/java"/>
 <classpathentry kind="src" path="src/test/resources"/>

BUT, interestingly enough, Eclipse does not read these entries because Eclipse loads only one .classpath file, which is the one in the root of the project rather than the subproject.

Otherwise, it seems it might have worked.

What is the secret to getting intellisense working in a multi-project build?

My project is at https://github.com/djangofan/WebDriverTestingTemplate and I am trying to alter the project to use the ‘eclipse’ plugin and get intellisense working.

I can get intellisense working somewhat, by including compiled .class files in the build path, but that doesn’t give me intellisense BEFORE I have compiled.


(Jon Austen) #2

In a further attempt to figure this all out, I tried this multi-project example ( https://github.com/gradleware/oreilly-gradle-book-examples/tree/master/multiproject-eclipse-plugin ) and it no longer works because it appears some of these declarations have been deprecated or changed since recent versions of Gradle have come out.

This no longer works… can anyone translate it to Gradle 1.4 for me?

classpath {
    downloadSources = true
    downloadJavadoc = true
    sourceSets = allprojects.collect { it.sourceSets.collect { it } }.flatten()
    pathVariables DEPENDENCY_CACHE: file("${gradle.gradleUserHomeDir}/cache")
          // This code will automatically pick up new subprojects as they are added.
    // It will include the compile, and runtime configurations.
    subprojectConfigurations = allprojects*.configurations*.matching {
      it.name in [ 'compile', 'runtime' ]
    }
    subprojectConfigurations.all.flatten().each {
      plusConfigurations << it
    }
        minusConfigurations << configurations.compile
    minusConfigurations << configurations.runtime
  }

(Peter Niederwieser) #3

If all projects (including the parent project) apply the ‘eclipse’ plugin, and all subprojects apply the ‘java’ plugin, then it should work out-of-the-box. Check out the samples in the full Gradle distribution.


(Jon Austen) #4

Ok, I will try examples from the current distro.


(Jon Austen) #5

I tried the ‘multiProjectBuildSrc’ sample that comes with Gradle 1.4 and it is much too vague and doesn’t answer any part of my question.

Also, the ‘water’ sample does not have an example of the ‘eclipse’ plugin as being part of it either.

I’ll try to fork the Gradle project on GitHub so I can show you the example not working.


(Peter Niederwieser) #6

How are you importing the project into Eclipse? Are you aware of the fact that Eclipse doesn’t handle hierarchical projects well? (Sadly, that’s why many teams use a flat directory layout.) If you need/want to use a hierarchical layout, you can either import subprojects individually (and live with the limitations of this approach), or use the Eclipse Gradle tooling, which offers first-class support for hierarchical projects.


(Jon Austen) #7

I am using “Eclipse Gradle” tooling, and this is where the root of my questions are from. I’m not particularly attached to any form of layout. I am just trying to figure out what is recommend and most of all “what works”.

What is particulary frustrating is the “intellisense” not working. I can use a flat layout (with Eclipse tooling), but my understanding is that in that case I would need to publish dependent projects to the local maven repo so that subprojects can use them? Even in that case I am not convinced “intellisense” will work for me.

I must be overlooking something obvious. Am I the only one with these questions?


(Peter Niederwieser) #8

By Eclipse Gradle tooling I’m referring to the Eclipse Gradle plugin developed by SpringSource. If that’s what you are using (and I encourage you to do so), you shouldn’t run Gradle’s ‘eclipse’ task, but use “Import as Gradle build” from within Eclipse. More information is available here.

I can use a flat layout (with Eclipse tooling), but my understanding is that in that case I would need to publish dependent projects to the local maven repo so that subprojects can use them

Not at all. See the chapter on multi-project builds in the Gradle User Guide, specifically the ‘includeFlat’ method. Anyway, when using the Eclipse Gradle tooling you can stick to a hierarchical layout.


(Jon Austen) #9

Ok, I initially tried using that “import” method you are suggesting but when I imported my hierarchal Gradle project, it ignores that fact and displays my heirarchal project in a “flat project” format in the Eclipse left hand navigation pane (IntelliJ did exactly the same thing).

For this reason, I decided that the Eclipse Gradle importer must have been BROKEN and so I decided not to import it that way. I thought it worked much better to use the “regular project import” and then “convert project to Gradle nature” afterwards because it retains the heirarchal tree in the left hand nav. I am sure others must have experienced this problem; do you understand how logic got me there?

So, you are telling me that I should try it again and give it another shot… and so I will give it a try and I will post my result later.


(Jon Austen) #10

I am still in progress working on trying the solution but getting an unsurmountable error (err with project location being wrong) when trying to import my Gradle project into Eclipse: https://gist.github.com/djangofan/4715447 . I think it may be relate to this bug: https://issuetracker.springsource.com/browse/STS-2997

. I use Gradle 1.4 and Eclipse Juno with Gradle plugin from the Spring 3.7 site.

What I am probably going to have to do is create a new flat mulit-project and then copy all my files into it manually to get it working. I will update this thread when I am done.


(Jon Austen) #11

Thanks Peter Niederwieser !

With your help, I converted my project to a flat layout and solved the “intellisense” issues while retaining a somewhat heirarchal layout.

https://github.com/djangofan/WebDriverTestingTemplate

I did run into a MAJOR roadblock beating my head against my desk for HOURS until I discovered that the Eclipse Gradle “Import Project” function pukes if you use the “includeFlat” syntax rather than using plain old “include” in the settings.gradle .

I was about to commit suicide until I figured that out.

Here is a new screenshot of my Eclipse layout: https://raw.github.com/djangofan/WebDriverTestingTemplate/master/eclipselayout.png

So, all is well. I wish it hadn’t been so tough to figure out though.


(Jon Austen) #12

I entered a bug on that issue I encountered:

https://issuetracker.springsource.com/browse/STS-3202


(Jon Austen) #13

Basically, as it turns out, the Eclipse Tooling plugin can import projects as “includeFlat” ONLY when the root project is a sub-directory of the “Eclipse Project root”, like so:

Eclipse Project Root
    -- RootProjDir
         settings.gradle
         build.gradle
    -- SubProject1
    -- SubProject2
    -- etc.

When I had a layout like this one (below) , it fails (unless you use ‘include’ rather than ‘includFlat’ ) :

Eclipse Project Root (a.k.a root project)
build.gradle
settings.gradle
    -- SubProject1
    -- SubProject2
    -- etc.

I thought this was ODD since, using the former layout (not latter), the command line gradle.bat build refers to the “Eclipse project root” as the “root project for Gradle” . Wierdness.