After running 'gradle eclipse', Eclipse says The App Engine SDK appengine-api-1.0-sdk-1.9.26.jar on the project's build path is not valid and is not a directory)

[jamesmortensen]

I have successfully installed and configured the Gradle Google App Engine plugin for Eclipse, and I'm now able to manage dependencies without the need to commit them to source control.

However, the setup is easily broken when new dependencies are required. Running gradle eclipse regenerates the .classpath file, but there's a problem that occurs due to Eclipse needing to know the location of the installed App Engine SDK. In order to resolve the issue, one must open Preferences -> Java Build Path -> Order And Export and then move all of the App Engine SDK libraries to the bottom while moving the installed App Engine SDK files to the top. Moreover, the library mentioned in the error message must be moved to the absolute bottom of the list in "Order and Export".

Description Resource    Path    Location    Type
The App Engine SDK '/Users/jem/.gradle/caches/modules-2/files-2.1/com.google.appengine/appengine-api-1.0-sdk/1.9.26/96df7122857b0b8ec0b478cb9fdac62bccdb89eb/appengine-api-1.0-sdk-1.9.26.jar' on the project's build path is not valid (SDK location '/Users/jem/.gradle/caches/modules-2/files-2.1/com.google.appengine/appengine-api-1.0-sdk/1.9.26/96df7122857b0b8ec0b478cb9fdac62bccdb89eb/appengine-api-1.0-sdk-1.9.26.jar' is not a directory)   Postfix_Calculator_TDD      Unknown Google App Engine Problem

Each time one runs gradle eclipse, the files must once again be manually moved to the bottom. _This is a a barrier to entry for the majority of average developers who are not active participants in the open source community._

Therefore, is it possible to make this more user friendly by configuring gradle so it moves these files to the bottom by default when running gradle eclipse? This information was incredibly difficult to find. Even finding the Stack Overflow link below, for reference in this thread, took about 30 minutes since I did not bookmark it. We should make this work smoother for folks, if possible.

Hope this helps. Please let me know if you need more details. I'm happy to help.

Additional Information:

• http://stackoverflow.com/q/4992693/552792
• https://github.com/GoogleCloudPlatform/gradle-appengine-plugin/issues/184

[loosebazooka]

I mean #184 explains it. The gradle appengine plugin's eclipse support is mostly generic, I don't think it plays well with the google plugin for eclipse (which largely depends on the eclipse builder).

We can try to fix this, but it's not the way it was intended to work (gpe has a different architecture). I don't have any eclipse projects handy, but do you have a .classpath file that I can compare against. I don't want to insert and gpe specific code in this plugin but maybe we can come up with some code that you can insert in your build.gradle that injects the appengineSDK dependency directly when running gradle eclipse.

[jamesmortensen]

For #184, the one thing that is missing is hot deploy, meaning that each time I change a file, the Eclipse builder reloads the dev appserver so that it doesn't need to be restarted. With the gradle appengine plugin, the dev server must be restarted manually after each change. Even something as simple as fixing a typo in a string requires a complete server restart.

This isn't a Gradle bug; instead, this is a lacking feature in the dev_appserver.sh command as part of Google App Engine. Eclipse solves a problem Google failed to solve.

However, if Gradle can work with the Google Eclipse Plugin, we keep the power of both Eclipse's App Engine integration as well as Gradle's eclipse and app engine integration.

Thanks for your suggestion to write code to modify the .classpath. I understand why you wouldn't want to put any GPE specific code in your plugin. So I will try to see if I can write a gradle task to do this manually. If I get it working, I'll post back here as it would make a great addition to a "Getting started with Gradle with Eclipse" article.

[loosebazooka]

Yeah, so historically this plugin has been blowing away the working directory on creation of the runnable war directory : see discussion #97

Yes, please keep me updated when you get it work!