Why does it quickly become unwieldy in Eclipse? From my experience, it's quite common to work on an app comprised of many Eclipse projects.

Keep in mind that the Gradle Eclipse plugin generates a lot more stuff than just the lib entries in the .classpath file. Merging all of that into a single Eclipse project could cause all sorts of conflicts. At the very least, it would result in Eclipse behaving very differently from the Gradle build. To give just one example, Eclipse would no longer prevent you from using a dependency that's not available in that subproject.

An alternative might be to stick to a single Gradle project and let it produce multiple artifacts. This seems to align well with your mental model of the project, and would create just one Eclipse project.

Perhaps I don't understand how multi-module projects are intended to work within Eclipse. Let's say that I have two build files:
java/com/benmccann/common/frontend/action/build.gradle
java/com/benmccann/common/frontend/server/build.gradle

Right now I believe that the Gradle Eclipse plugin generates .project files next to both of those build files. But I'm not sure that you can have the .project files that deep in the directory structure. How do you import those into Eclipse in any meaningful way? Also, if you have a couple dozen of them, I'm not sure how to import them except to do it manually one by one. I love that Gradle doesn't force me to use the Maven project structure, but I feel that the Eclipse plugin it really geared towards that use case.

I'm only suggesting that the Eclipse plugin update the classpath when running in 'single project' mode. I actually don't have any problem with the fact that Eclipse will allow me to use a dependency that's not available in the subproject. I setup Eclipse to run a gradle compilation whenever Eclipse does a build (Properties > Builders, fill out the info on main tab, and select During auto builds), so I would immediately be alerted to that and never actually run into that problem. (Actually, having the Eclipse plugin automatically set this up might be nice in 'single project' mode as well.)

I think you get a lot of trouble if your gradle subprojects doesn't match your eclipse projects.

A typical layout:

build.gradle (subprojects

)
settings.gradle (include "dao", "frontend")
dao/build.gradle
dao/.projects
dao/.classpath
dao/src/main/java/com/benmccann/common/db/dao/MyDAO.java
frontend/build.gradle
frontend/.projects
frontend/.classpath
frontend/src/main/java/com/benmccann/common/frontend/MyFrontend.java
...

The problem I have with that is that it forces the Maven layout upon you, which is something that Gradle avoids until you start using the Eclipse plugin. Using the Maven layout makes all the classes live three directories deeper, which I really don't like. We use a single Eclipse project to build multiple projects at Google with our own build system and Eclipse plugin all the time and there's never been a situation where I've had difficulty with the two being different. It might sound a bit odd at first if you're coming from a Maven directory structure and are in that mindset. However, if you set Gradle up to build the project within Eclipse there really shouldn't be any problem.

> But I'm not sure that you can have the .project files that deep in the directory structure. How do you import those into Eclipse in any meaningful way?

File->Import->Existing Projects into Workspace, and select a common parent directory. All projects will be found and imported in one go.

> I love that Gradle doesn't force me to use the Maven project structure, but I feel that the Eclipse plugin it really geared towards that use case.

It's geared towards the way Eclipse handles multi-projects.

After some more discussion with Adam, we have come to the conclusion that we are not going to add a "single-project" mode to the Eclipse plugin at this point. But what we would like to do is to make it easier to reuse the Eclipse tasks separately from the plugin. The idea being that if you are happy to configure the tasks without the help of the plugin, you should be able to generate a single Eclipse project from a multi-project Gradle build without reinventing the wheel.

Thanks Peter. That certainly seems reasonable. I'm trying to restructure my project in the way you suggested and I ran into a couple small frustrations. Perhaps rather than working on the "single-project" mode, which it seems like I'm the only one asking for, it'd be better to solve these issues instead.
The first is that if I apply the Eclipse plugin on my base project, I'm then unable to import my subprojects (File->Import->Existing Projects into Workspace). If I only apply the Eclipse plugin to my subprojects, and leave it off my base project, it will then import all the subprojects. However, I'd like to import the base project as well because I have some files in my base project that I'd like to edit without having to go to the command line or file explorer (none are Java files, but there are things like build.gradle, settings.gradle, etc.).
The other issue I faced was that the jars being imported are all listed directly under the project. This makes for a lot of scrolling to find the comparatively few Java packages. I really like what Maven does, which is to have a container that they are under so that they can be collapsed and do not take up all the room in the project explorer.
I upgraded to 1.0-milestone-1 and still faced both of these issues.

I filed the two issues I just mentioned as new JIRA tickets:
http://jira.codehaus.org/browse/GRADLE-1413
http://jira.codehaus.org/browse/GRADLE-1414

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.