Sub-projects are ignored?

Old Forum
1

I’ve created a small example, using the supplied ‘flat-java-multiproject’ in Eclipse Gradle.

The template project consists of three projects: A top-level build project called Example, and two sup-projects called my-lib and product.

In the main (parent/root) project, the settings.gradle contains a reference to the dependencies:

include "my-lib", "product"

The build.gradle should supposedly build the subprojects:

subprojects {
    apply plugin: 'java'
    apply plugin: 'eclipse'
      repositories {
       mavenCentral()
    }
      dependencies {
        testCompile 'junit:junit:4.8.2'
    }
      version = '1.0'
      jar {
        manifest.attributes provider: 'my cool company'
    }
}

When I run the build.gradle above. the output appears to indicate that the sub-projects are being built. Problem is that they aren’t. The sub-projects are not being built when running the build.gradle in the parent project. It appears that Gradle doesn’t even care if the sub-projects even exist (I’ve tried to change the names in the settings.gradle file. It pretends to build the sup-projects, even though they don’t exist!)

Hope you can help me. This one is really getting the best of me!

Kind regards,

Povl

2

Sounds like the actual directory structure doesn’t match what you configured. For a “flat” directory layout, you’ll have to use ‘includeFlat’.

3

I’ve tried to includeFlat instead of simply include, but the result is the same. The output “simulates” the projects being built, but not build is actually taking place. The output below is taken after deliberately making a compile error in my-lib - it cannot compile.

What am I missing here??

[sts] -----------------------------------------------------
[sts] Starting Gradle build for the following tasks:
 [sts]
    clean
[sts]
    build
[sts] -----------------------------------------------------
:my-lib:clean
:product:clean
:my-lib:compileJava UP-TO-DATE
:my-lib:processResources UP-TO-DATE
:my-lib:classes UP-TO-DATE
:my-lib:jar
:my-lib:assemble
:my-lib:compileTestJava UP-TO-DATE
:my-lib:processTestResources UP-TO-DATE
:my-lib:testClasses UP-TO-DATE
:my-lib:test UP-TO-DATE
:my-lib:check UP-TO-DATE
:my-lib:build
:product:compileJava UP-TO-DATE
:product:processResources UP-TO-DATE
:product:classes UP-TO-DATE
:product:jar
:product:assemble
:product:compileTestJava UP-TO-DATE
:product:processTestResources UP-TO-DATE
:product:testClasses UP-TO-DATE
:product:test UP-TO-DATE
:product:check UP-TO-DATE
:product:build
  BUILD SUCCESSFUL
  Total time: 0.326 secs
[sts] -----------------------------------------------------
[sts] Build finished succesfully!
[sts] Time taken: 0 min, 0 sec
[sts] -----------------------------------------------------

Renaming the sub-project references in settings.gradle to something that does not exist creates no error or warning - it simply changes the text on the output, pretending to compilt, test etc.

Runing the build.gradle script with eclipse argument (to set-up the Eclipse envirinment for the project), doesn’t seem to have any effect on the Eclipse set-up with respects to project dependencies.

4

As I said, the actual directory structure likely doesn’t match the configured one, and so all that Gradle sees is empty source directories, which it happily compiles. Perhaps post a tree view of the directory layout, including locations of ‘settings.gradle’ and ‘build.gradle’.

5

Thank you for your quick reply again, Peter!

The root project is placed at workspace/Example

In this I have the build.gradle:

subprojects {
    apply plugin: 'java'
    apply plugin: 'eclipse'
      repositories {
       mavenCentral()
    }
      dependencies {
        testCompile 'junit:junit:4.8.2'
    }
      version = '1.0'
      jar {
        manifest.attributes provider: 'my cool company'
    }
}

and the settings.gradle:

includeFlat "my-lib", "product"

The two sup-projects are

Project my-lib, placed under workspace\Example\my-lib with the following build.gradle:

dependencies {
 compile group: 'commons-collections', name: 'commons-collections', version: '3.2'
}

Project product, placed under workspace\Example\product with the following build.gradle:

dependencies {
 compile project(':my-lib')
}

Than you again for your help and support - it’s much appreciated!

6

As the project directory structure is hierarchical, you’ll need to use ‘include’ rather than ‘includeFlat’. In case this doesn’t solve the problem, where are the source files located?

7

Thank you, Peter! I think we’re closing in on this…

I’m back to include rather than includeFlat. I added

sourceSets {
  main {
   java {
    srcDirs = [ 'src/main/java' ]
   }
  }
 }

to the subprojects section of the parent project, and that made Gradle compile the sub projects, reporting errors and all. Shouldn’t this be the default path to the source files?

But!

When I try to clean build on the sub project my-lib, I get a lot of these errors:

org.springsource.ide.eclipse.gradle.core.InconsistenProjectHierarchyException: Gradle project hierarchy is inconsistent for 'my-lib'
 at org.springsource.ide.eclipse.gradle.core.util.ExceptionUtil.inconsistentProjectHierachy(ExceptionUtil.java:82)
 at org.springsource.ide.eclipse.gradle.core.GradleModelProvider$GroupedModelProvider.getCachedModel(GradleModelProvider.java:334)
 at org.springsource.ide.eclipse.gradle.core.GradleProject.getGradleModel(GradleProject.java:542)
 at org.springsource.ide.eclipse.gradle.core.GradleProject.getGradleModel(GradleProject.java:537)
 at org.springsource.ide.eclipse.gradle.core.classpathcontainer.GradleClassPathContainer.getClasspathEntries(GradleClassPathContainer.java:136)
 at org.eclipse.jdt.internal.core.JavaModelManager$VariablesAndContainersSaveHelper.saveContainers(JavaModelManager.java:4144)
 at org.eclipse.jdt.internal.core.JavaModelManager$VariablesAndContainersSaveHelper.saveProjects(JavaModelManager.java:4211)
 at org.eclipse.jdt.internal.core.JavaModelManager$VariablesAndContainersSaveHelper.save(JavaModelManager.java:4052)
... (truncated)...

Same for sub project product…

What is this? The main project compiles, but the sub projects doesn’t?

8

Shouldn’t this be the default path to the source files?

It is the default. If adding that line makes a difference, then something in your build has reconfigured the defaults.

What is this?

Never seen this before. To track this down, I suggest that you first get the command line build working, and only then switch back to Eclipse.

9

Hi there.

After some further investigation, I found a couple of problems, partly related to Eclipse and the Gradle plug-in for Eclipse (Greclipse).

Since the set-up I was using was taken straight from the Eclipse plug-in as a template, I’ll try to report this to the Greclipse team.

Thank you again for your support and fast replies!!

// Povl

10

Povi,

Would you be able to post an update with the solution, or a link to the solution?