I'm not sure. In case of Gradle you can avoid your issue by importing with subprojects as root. Additionally you can tweak Eclipse to accept a hierarchical layout in which case you would need the top level eclipse files.

Another example of this is in the samples/java/multiproject. "gradle eclipse" generates .classpath and .project files for the services directory as well as the 2 subdirectories shared and webservice inside it. But "services" itself is not a project, not listed in the settings.gradle, and is really nothing more than a directory that happens to contain subprojects. It seems incorrect to me to generate .project and .classpath entries for the services directory.

gradle eclipse
find . -name .classpath
./api/.classpath
./services/.classpath
./services/shared/.classpath
./services/webservice/.classpath
./shared/.classpath

@Philipp The services is added in the settings.gradle. For good or bad, the current default policy is to add the dirs between leafs and root automatically as projects. I fully see your point though. This is something we need to think about. At least provide some easy ways to express what you want. Of course you can always do a eclipseClasspath(Project).enabled = false for a specific project. But this is not very nice.

I don't think we want to fix it this way. For example, if I don't pull the 'gradle' project into eclipse I cannot work on the root 'build.gradle'. Yet, I agree it is somewhat annoying that eclipse import wizard does not show all recursive projects

As far as not generating the eclipse projects for subfolders - the way to work around it could be applying eclipse plugin to selected projects either explicitly or using filter:
configure(subprojects.findAll

)