In order to workaround Eclipse’s poor hierarchical project support, we converted our project to use a master folder for the root project and utilized the includeFlat method to create a completely flattened set of projects in Eclipse without any nesting. This imports fine and builds fine but now BuildShip appears to be disabling all of the tasks listed in the Gradle Tasks view for any project within these sets of projects. I am using Eclipse 4.5.2 and BuildShip 1.0.16.
I’d advise against flat layouts, they are such a hassle to use on the command line.
That project’s settings.gradle is broken in several ways, so it’s surprising it does anything at all:
includeFlat does not support a hierarchy below the included projects. All projects need to flattened.
if you do want hierarchical projects, their name should be separated by a colon ‘:’, not a ‘/’. (I’ve seen that error a lot and I’d be curious where it comes from? Is there some misleading guide out there that tells users to use slashes? Our documentation shows colons in all places.)
For nested projects, eclipse models internal data structures that these projects are actually independent. Through some UI level constructs, you can make it appear that Eclipse is understanding the nested structure but it isn’t at a fundamental level.
This results in Eclipse keeping track of the same file on disk multiple times. The UI resource lookups and searches show double, triplicate, etc. results depending on how nested your project structure is. We have a large 75+ gradle modules with millions of lines of code with 3 levels of nesting and Eclipse performance suffers.
It is slightly more inconvenient to have to reference the gradlew file in the master directory but gradlew is already awkward to use with hierarchical projects as you need to point to the relative location of it in the root project. A large portion of our developers spend all of their time in Eclipse so it really doesn’t matter much to them either way as long as Eclipse works normally.
The sample project works fine for me and builds normally from the command line and can be imported into eclipse without an issue. We aren’t defining a hierarchy in the sample project’s settings.gradle. It is defining 4 subprojects that happen to themselves be in subfolders. The API for includeFlat just states that it takes the passed parameter as the project name and uses it relative to rootDir/.. to set the subproject directory.
Back to the original question though - is it expected that Buildship disables the tasks in the task view for these projects?
The resource view has a Hide duplicate resources option.
Exactly, it is the name of the project, which should not contain any slashes. The build might work for you right now, but I can tell you that you will run into other funny bugs if you use includeFlat like this. Buildship is just the tip of the iceberg here.
For instance, just cd into as/a1 and run gradle projects there. You’ll see that it says “Root project a1”, because it does not go up two levels to find the master project.
Again, includeFlat means the subproject needs to be on the same level as the root project, not nested somewhere else.
I’ll bring this up internally, we should add a deprecation warning for this and for slashes in project names.
It’s expected in this case as the project is broken. It works if includeFlat is used as intended.
This only hides duplicate resources from the one resource lookup view. The search still returns duplicates and a bunch of extraneous files are shown in the resources lookup as it finds the .class files from the leaf project’s derived folders but sees them through the parent projects enclosing those leaf projects. It is possible to ignore this but Eclipse’s nested project support is a thin veneer at the UI level.
I don’t think you are correct. When I run gradle projects from as/a1, it shows just the :a1 project which is the same behavior that gradle projects exhibits when run from a leaf project on a normal hierarchical based project. Further, if you run gradle tasks from as/a1, it correctly shows the list of Java tasks available to run that it could only have configured itself by finding the …/…/master/settings.gradle and …/…/master/build.gradle that applies the java plugin to all subprojects.
It seems to work fine although I hear you that you don’t see this as intending to be supported.
Ok. Will take this under advisement. Puts us in an awkward position of poor eclipse support for hierarchical builds and lack of strong support for flattened projects from gradle per your recommendation to avoid it.
Sorry you’re right, I missed an important detail: You fix the project names again from slashes to dashes. So this actually leaves you with a valid, yet non-standard project layout. Support for such layouts might improve in Buildship 2.0.
Let me provide another option though: You can use a hierarchical layout (maybe not a too deeply nested one, just one layer or two) and add resource filters to your Eclipse projects to ignore the subproject folders.
Buildship no longer does this because the generic approach of “1 filter per sub-project” lead to worse performance than just not filtering anything. But if you can come up with a better filter (e.g. “all folders under this one”), it should work nicely.
We plan to support resource filters in Gradle’s Eclipse model at some point so you could even automate their creation in the future.