[GRADLE-196] EclipseClasspath and EclipseWtp task should be able to use relative project paths and variable paths. Created: 28/Aug/08 Updated: 04/Jan/13 Resolved: 24/Nov/10 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | None |
Fix Version/s: | 0.9-rc-1 |
Type: | Improvement | ||
Reporter: | Hans Dockter | Assignee: | Hans Dockter |
Resolution: | Fixed | Votes: | 9 |
Description |
Right now libraries are always described by their absolute path in the descriptor files. This makes the descriptor files unportable. |
Comments |
Comment by Martin Vlcek [ 06/Nov/08 ] |
For Eclipse class path, which points to .../.gradle/cache/..., you could replace the part before /.gradle/cache with USER_HOME and create a classpath extending the variable USER_HOME. Each user just has to set this variable once and all projects will be ok. For IntelliJ I didn't find a feature similar to Eclipse classpath variables. |
Comment by Hans Dockter [ 06/Nov/08 ] |
Probably this is the way to go (like the Maven Eclipse plugin works). IntelliJ has some concept for this. I haven't fully figured it out yet. Unfortunately we don't have any IntelliJ file generation yet. |
Comment by Helmut Denk [ 20/Nov/08 ] |
>>For Eclipse class path, which points to .../.gradle/cache/..., you could replace the part before /.gradle/cache with i think it would be better to use Classpath-Variable GRADLE_REPO as Classpath-Variables are bound to eclipse-workspace and workspaces |
Comment by Hans Dockter [ 28/Nov/08 ] |
We also have the use case that there are resolvers which don't use the cache for the jars. Like the resolver you get with addFlatDirResolver. Usually in such a case the libs live in svn and are relative to the project root. We also need to offer to use classpath variables in such a scenario. |