Run configurations (aka launchers) should not be constantly created and destroyed. If you are developing an application you will probably manually define one or several launchers. Selecting Run as… Simply create a default launcher, but there is little chances that it suits your needs. It only selects the project and main class, and set the working directory to the project diriectory. You would probably need to set the application parameters, the JVM parameters, the runtime classpath, the environment variables, and so on. As the launcher should probably be shared, you would also choose to save it in the project (rather than in the workspace) in order to add it to your VCS system.
Having the runtime dependencies added to the compile classpath only saves you the runtime dependencies configuration. On the other hand, having all dependencies (compile, test, runtime, either direct or transitive) mixed in the Eclipse compile classpath is a very bad thing because it creates dependencies that are not supposed to exist, destroying the modularity of the application.
How can this work in practice ? We use a build file in which runtime dependencies are included in conditionnal blocks. The condition tested is a parameter that must be set to true when build with gradle, and is implicitely false when importing into eclipse. We use the same principle for transitive dependencies, setting the transitive property to the value of the parameter. (One consieaunce is that we have to define transitive compile as direct, which is perfectly ok since I do not believe that “transitive compile” has any reasonable meaning.
We also use a custom task that open all launchers, removes the existing dependencies (if any) and adds the runtime dependencies. This is a simple task since a launcher is a simple XML file with a .launch extension.
The only trouble is that it is not dynamic, i.e. it has to be done manually each time dependencies are changed in the gradle build file. But this is also true for compile dependencies, so it is not a problem.
What is missing is the possibility to use parameters when importing into Eclipse. (I believe this is a limitation of the gradle api). The work around is to make the default configuration (no parameters) work for Eclipse and use parameters when the build is done on the CI server or locally through the gradle command line.