[GRADLE-1134] Elipse complains about dependences not being exported Created: 26/Aug/10 Updated: 04/Jan/13 Resolved: 24/Apr/12 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 0.9 |
Fix Version/s: | 1.0-rc-1 |
Type: | Improvement | ||
Reporter: | Felix Gnass | Assignee: | Szczepan Faber |
Resolution: | Fixed | Votes: | 4 |
Description |
Using the Gradle-generated .classpath file in Eclipse 3.6 yields the following warning for each referenced library: Classpath Dependency Validator Message: Classpath entry GRADLE_CACHE/xxx.jar will not be exported or published. Runtime ClassNotFoundExceptions may result. Eclipse offers a Quick-Fix, which (when applied to each entry) makes the warnings go away. The Quick-Fix modifies the classpath entries so that ... <classpathentry exported="true" kind="var" path="GRADLE_CACHE/xxx.jar" sourcepath="..."/> ... becomes: <classpathentry exported="true" kind="var" path="GRADLE_CACHE/xxx.jar" sourcepath="..."> Workaround: eclipseClasspath.withXml { xml -> .each { it.appendNode('attributes').appendNode('attribute', [name: 'org.eclipse.jst.component.dependency', value: '/WEB-INF/lib']) }} PS: Sorry for spamming you with all the Eclipse related issues lately. The new Eclipse plugin really rocks and it's impressive that all the issues can be easily worked around with a few lines of Groovy code. |
Comments |
Comment by David Resnick [ 16/Nov/10 ] |
As a result of gradle-0.9-rc-3 creating lib classpathentries instead of var, the workaround needs a small fix: eclipseClasspath.withXml { xml -> .each { it.appendNode('attributes').appendNode('attribute', [name: 'org.eclipse.jst.component.dependency', value: '/WEB-INF/lib']) }} |
Comment by Szczepan Faber [ 17/Mar/12 ] |
Just wanted to give a heads up how I'm planning to resolve the issue. For more discussion, see Plan: Every library/variable dependency (basically, jars) in the .classpath is marked as 'nondependency' by default if the 'eclipse-wtp' plugin is applied. The wtp component file manages and configures the deploy path. It is a slightly different approach than suggested, e.g. I'm using the 'org.eclipse.jst.component.nondependency' vs 'org.eclipse.jst.component.dependency'. However, this solves the problem and keeps things consistent with the existing approach (e.g. the component file '.settings/org.eclipse.wst.common.component' manages the deployable libraries). |
Comment by Szczepan Faber [ 24/Apr/12 ] |
There should be no more warnings. For more discussion see |