I am using gradle and have IDEA configuration pointing to .gradle/cache jar file locations. Now with the new milestone, the location has changed, but it feels like its no longer “constant”. Can the new location change between machines?
We now cache dependency artifacts on a per-resolver basis. This has provided a number of benefits, particularly in reproducibility of builds. (Previously it was possible for a cached artifact to be used even if it wasn’t available from any configured repository).
So the path to any cache file now contains a repository identifier, that uniquely identifies the DependencyResolver used to download the artifact. This will not change per-machine, but can change if you change repository configuration.
A better solution to your problem might be to use the ‘idea’ plugin to generate your IDEA project and module files. That way, you can easily update your configuration when the set of dependencies changes, and you get the dependency sources linked automatically.
I avoid the idea plugin intentionally because the idea project files include several custom project level settings… . Thats a real deal breaker for me, to be honest, which forces me to stay with m3. Is there a chance to have an option to configure the build file to use my own identifier or something similar in order to solve it?
The cache layout is considered a private implementation of Gradle and isn’t designed to be used directly. In the future we may provide a more stable, user-friendly view into the cache, but for now it’s not designed to be used that way.
A few of options for you to try: - Just use the ‘ideaModule’ task to replace the .iml files while leaving your .ipr files alone. - Look at the “Modifying the XML representation” section in http://gradle.org/current/docs/userguide/idea_plugin.html - Use a Gradle task to extract all of the project jars into a separate directory, in whatever format you like. You might want to look at http://gradle.org/doc/org.gradle.api.artifacts.ResolvedDependency for this.
Thanks for the reply, but if thats the way gradle is going to work, its problematic for me. Personally, I think its a bad decision for gradle to make. Will stick with m3 for now, and might have (don’t really want to…) move away in the future. Thanks for all the hard work!
As I’m sure you can imagine, there are many factors influencing our design decisions. Without changes to the cache structure, we wouldn’t able to provide a whole heap of features, improvements and general goodness.
http://forums.gradle.org/gradle/topics/welcome_to_our_new_dependency_cache
We don’t want to end up being locked into a fixed cache layout, and find that it’s impossible to support the sort of improvements we are planning.
Is there a specific reason that none of the options I suggested will work for you? We are always looking for real issues that can drive our design decisions.
Sure, I completely understand. I don’t fully follow the reasoning behind the change, but I am sure it has sound reasoning behind it.
All the other solutions for this go in the way of “keeping this simple” (at least in my point of new).
I don’t believe in letting the build system generate the IDE project files. Its bad with maven, and for the same reasoning, bad with gradle. The support to import a maven project and track it in IDEA is superb compared to maven generating project files. gradle does not have a good IDE support, and its something that is going it stay for the near (probably long) future. Certainly compared to maven.
I find the committed IDEA project file a solution that is better compared to the ones suggested, and if I can’t use it now, I need to think what to do next.
The cache location changed again for milestone-6. Unlike Shay, I do use gradle to generate/maintain my Eclipse files and it works well for my needs. The problem is that the .classpath files contains absolute file paths which doesn’t work well if different developers have different paths to gradle. To work around this I use something like this:
eclipse {
pathVariables ‘GRADLE_CACHE’:
file("${gradle.startParameter.gradleUserHomeDir}/caches/artifacts-4") }
For this to work, all developers using Eclipse have to set an Eclipse classpath variable, GRADLE_CACHE.
It would work better if gradle took care of this and we could simply configure the gradle Eclipse object with the name of the classpath variable we want to use, or simply a use a default value of GRADLE_CACHE. Then it wouldn’t break whenever upgrading gradle. With milestone-5 , it used a path containing artifacts-3 instead of artifacts-4.
We find that using only ideaModule task works very well for us. Since the .iml file is simply XML mapping to jar files, we are very happy to let Gradle produce that from the its dependency configuration.
This allows us to manually manage the .ipr (or .idea directory) and have those files checked into source control. Conversely, the .iml file is set to be ignored so generated paths do not need to be made multiple-machine generic.
We remap the “idea” task to only produce the .ipr file (this is M6+ convention).
tasks.idea.dependsOn = [ cleanIdeaModule, ideaModule ]
When you update your build.gradle dependencies, simply run “gradle idea”. If somone on the team updates a dependency they broadcast that people should “re-gradle”. (Having Gradle ‘know’ when the .iml file is out-of-sync would be a great addition!)
Overall, this setup works great for us!
Thanks for the feedback. I like to use ideaModule too; for one it doesn’t force a project reload. It’s pretty rare that something changes requiring the .ipr file to be updated.
Good idea about avoiding absolute paths in .classpath files. Would you mind posting your idea as a new forum topic? We could then use our new Jira integration to track it as an issue. Thanks.
Happy to do so.
the new topic was posted yesterday as “removing absolute paths from Eclipse .classpath file”