I have a large team sharing eclipse project files stored in source control (legacy behavior that I don’t want to change). The .classpath files generated by the Eclipse plugin are very user specific. If I use path variables that point to the gradle caches directory (~/.gradle/caches/), will everything beyond that be generic enough to share around the team?
The best way to find out is to have a look at the generated files.
I guess the question I’m asking is if the path/filenames under the caches directory are deterministic and will be generated the same on all machines that run gradle (same version) or will they be machine specific?
Yes, they will be deterministic (for the same Gradle version).
As of gradle 1.7 there appears to be a sha-sum in the path of the downloaded artifacts. e.g. an artifact test.jar gets downloaded to a path like:
GRADLE_HOME/caches/artifacts-26/filestore/group/artifact/version/jar/shasum-of-jar/test-version-SNAPSHOT.jar
So when I make changes to the test project, this gets resolved to a different path on a subsequent resolve, and breaks the .classpath files.
Is there another approach I should be taking to sharing Eclipse settings with my team? Perhaps I can define a custom resource path?
Thanks
The usual recommendation is not to share Eclipse files, but to regenerate them using Gradle whenever necessary. Alternatively, you could use the Eclipse Gradle plugin, which gets the dependency information straight from Gradle.
Hey Peter,
In our CI environment, artifacts are constantly being updated and downloaded. The regeneration of Eclipse files in this situation would add an extra step to our CI process that we would not have with maven or ant+ivy (not saying those tools are better, just looking for ways to make gradle better)
Are you referring to the Eclipse plugin from: http://dist.springsource.com/release/TOOLS/gradle ?
Using your advice I was able to resolve the classpath issue by right clicking > Gradle > Enable Dependency Management. From there, I went to right clicking > Gradle > Refresh Dependencies. This made my .classpath turn into:
<classpath>
<classpathentry kind="src" path="src/main/java"/>
<classpathentry kind="src" path="src/main/resources"/>
<classpathentry kind="src" path="src/test/java"/>
<classpathentry kind="src" path="src/test/resources"/>
<classpathentry kind="con" path="org.eclipse.jdt.launching.JRE_CONTAINER"/>
<classpathentry exported="true" kind="con" path="org.springsource.ide.eclipse.gradle.classpathcontainer"/>
<classpathentry kind="output" path="bin"/>
</classpath>
Which does exactly what I want… resolves those dependencies dynamically. Note to those who may come later and try to copy and paste the above into their .classpath files… don’t do it. I tried that from an older post and found the org.springsource.ide.eclipse.gradle.classpathcontainer had changed packages from the post I copied from. So don’t copy the above, use the IDE to generate it. I’m just adding it here for clarification.
Thanks again for all your help. We are continuing to adopt gradle and the quick support helps with that.
I spoke to soon. I think that by adding a classpath entry of the form:
classpathentry exported=“true” kind=“con”
path=“org.springsource.ide.eclipse.gradle.classpathcontainer”
that this resolves the problem
I got this by right clicking the project > Gradle > Enable Dependency Management as described here: http://static.springsource.org/sts/docs/2.9.0.old/reference/html/gradle/gradle-sts-tutorial.html