[GRADLE-1575] compile dependencies mixed with groovy depencencies (commons cli) Created: 26/May/11 Updated: 23/Jan/13 Resolved: 23/Jan/13 |
|
Status: | Resolved |
Project: | Gradle |
Affects Version/s: | 1.0-milestone-2 |
Fix Version/s: | None |
Type: | Bug | ||
Reporter: | Daniel Gredler | Assignee: | Unassigned |
Resolution: | Not A Bug | Votes: | 0 |
Attachments: | test.zip |
Description |
Using the following example build script: apply plugin: 'groovy' repositories { mavenCentral() } dependencies { groovy 'org.codehaus.groovy:groovy:1.8.0' compile 'commons-cli:commons-cli:1.1' } Groovy 1.8.0 uses Commons CLI 1.2 [1], but if you specify that your project contains a user-defined compile dependency on Commons CLI 1.1 (as I do above), then version 1.1 gets used not only on the compile classpath, but also on the Groovy compilation classpath. So e.g. if you run "gradle compileGroovy --debug", here is an example of the log of the (erroneous) command line used:
As you can see, there are two classpaths: the run classpath used to run the FileSystemCompiler class, and the compile classpath. Both of these classpaths contain two versions of Commons CLI: version 1.2 included with Gradle, and version 1.1 specified by the user as a compile dependency. In my opinion the run classpath above should contain only Gradle's version of CLI, whereas the compile classpath should contain only the user-specified version of CLI, not Gradle's version. [1] https://svn.codehaus.org/groovy/tags/GROOVY_1_8_0/build.gradle |
Comments |
Comment by Daniel Gredler [ 26/May/11 ] |
attaching test project |
Comment by Daniel Gredler [ 26/May/11 ] |
I should have mentioned that this mixing of two versions of CLI, specifically on the compilation run classpath, results in version 1.1 being used instead of version 1.2. Version 1.1 behaves differently from version 1.2, the result being that of the two "-Jsource=x -Jtarget=y" arguments, the second one gets interpreted as a file path, resulting in the following compilation failure:
|
Comment by Luke Daley [ 23/Jan/13 ] |
This is standard dependency conflict management. You should use the `groovy-all` jar which internalises its dependencies to avoid this problem. |