[GRADLE-1719] The eclipseClasspath task generates incomplete .classpath entries Created: 04/Aug/11 Updated: 04/Jan/13 Resolved: 16/Mar/12 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 1.0-milestone-4 |
Fix Version/s: | None |
Type: | Bug | ||
Reporter: | Marian Seitner | Assignee: | Unassigned |
Resolution: | Not A Bug | Votes: | 0 |
Description |
The following dependency definition causes gradle to put the jar in the classpath and to copy it into the resulting web archive's lib folder, which is perfectly fine. // makes it in the classpath and in the resulting war Using the eclipseClasspath task the following entry is generated (among others): <classpathentry sourcepath="/path/to/spring-web-3.0.5.RELEASE-sources.jar" kind="lib" path="/path/to/spring-web-3.0.5.RELEASE.jar" exported="true"/> While this puts the jar into the class path, it gets neither exported in Eclipse (e.g. using the 'export to war file' wizard) nor published to a server. Fixing this problem by changing the project deployment assembly leads to slightly different entries: <classpathentry sourcepath="/path/to/spring-web-3.0.5.RELEASE-sources.jar" kind="lib" path="/path/to/spring-web-3.0.5.RELEASE.jar" exported="true"> The dependencies in the compile and runtime configuration should be created in the latter form because they are most likely intended to be shipped. |
Comments |
Comment by Szczepan Faber [ 16/Mar/12 ] |
Hello, This is not a bug. Provided you apply the 'eclipse-wtp' plugin, gradle will generate a wtp component file that correctly describes exported and unexported libraries. A different task creates this metadata (ie. not eclipseClasspath but ecipseWtpComponent) but that's not really an issue - most users execute 'gradle eclipse' anyway. I'm closing this issue if that's ok unless there are compelling reasons we should not use the wtp component metadata and configure the wtp exports/unexports in the .classpath. However, there's one related bug you should know about: |