[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. |