Eclipse classpath files with absolute file pathes

Old Forum
1

This problem was already in discussion 2 years ago (http://forums.gradle.org/gradle/topics/removing_absolute_paths_from_eclipse_classpath_file), but did not end with a solution to the problem with absolute pathes of classpath entries of used libraries.

The problem manifests when you want to shield team users from underlying gradle build scripts. They shold just work with Eclipse projects the usual way - using generated Eclipse classpath and project files, checked in into SCM. When this scenario is wanted, you cannot have absolute path names in “.classpath” files if you don’t want your team users to have all the same absolute path for the projects.

So my idea was to have the Gradle cache relative to the root (or some other) project and have only relative pathes in “.classpath” files. This is possible when you hook into eclipse generation “whenMerged”. Here we can replace the entry path on nodes with kind “lib” with a relative name. But: the same thing is not possible by API when you want to replace the value of attribute “sourcepath” (the path to downloaded source jars) ; this value is only readable, not writeable.

Is there any solution? Or do we have to write a task with takes the generated “.classpath” files and do the replacement the workaround way?

1 Like
2

I agree with you that it is preferable to use relative paths in these metadata files where possible. You should be able to achieve that using ‘withXml’ hook described in http://www.gradle.org/docs/current/userguide/eclipse_plugin.html

There is another possibility: if you use Gradle plugin for Eclipse (developed by Pivotal) you can configure it to use Gradle classpath container. Your ‘.classpath’ file will be significantly reduced and Eclipse will compute classpath on demand during runtime.

I am not sure why you want to shield your team from your build system and lock them with Eclipse. Probably because you want to hear ‘works on my machine’ excuses. :wink:

3

You should be able to achieve that using withXml This hook works. But there is no API for changing the attribute “sourcepath” of a node…

shield your team from your build system and lock them with Eclipse Because our Application consists of an Eclipse client, Eclipse PDE is the leading system for developper; Gradle simply doesn’t support a PDE build. Therefore Gradle is uses a) as the build tool running on the build server and b) as the tool for managing dependencies, as far as they are not described by PDE Manifest. Here, there is sure a nasty gap.

4

I found another problem with Eclipse integration using the STS-plugin. Obviously this plugin doesn’t care (or does not know) about an overriden configuration of the Gradle cache (“org.gradle.user.home” in gradle.properties). It simply uses Gradle’s default value of it, USER_HOME/.gradle. This is not what I have when I build on the command line with gradle where I can have the gradle cache directory near my project’s directories. I have found no configuration option where I could set a value; it should use the root’s project “gradle.properties” anyway.

When I throw away the default gradle cache and open Eclipse with STS-plugin enabled, it will immediately download all 3rd party jars from our repository and put it into default gradle cache (saying after 8 minutes: “BUILD SUCCESSFUL”).

So for me the question is at the moment: should I use STS-plugin in Eclipse at all? What can I gain from it? After all, within Eclipse we have to build with Eclipse PDE Compiler.