depfail.zip
[GRADLE-694] Artifacts portion of dependencies disappear when depending upon project with war task Created: 12/Oct/09 Updated: 04/Jan/13 Resolved: 24/Nov/10 |
|
| Status: | Resolved |
| Project: | Gradle |
| Affects Version/s: | 0.8 |
| Fix Version/s: | 0.9-rc-1 |
| Type: | Bug | ||
| Reporter: | Spencer Allain | Assignee: | Hans Dockter |
| Resolution: | Fixed | Votes: | 0 |
| Attachments: |
depfail.zip
|
| Description |
|
I have a multi-project configuration where one subproject generates a war file and a jar file. Another subproject depends on the jar from the first subproject to compile (made that work by specifying that it just depends upon the jar artifact of the first subproject) and generate its own war file (which does not work). Any of the first subproject module dependencies that had explicitly named artifacts seem to be missing, at it looks just for the module name as the artifact name which fails miserably. This does not happen with just the jar task, so something is incorrect in the way the war task affects dependencies revealed to other consumers. subproject 1 } At the war building phase of subproject 2, it looks for 'net.java:jsf:1.2' without the artifact information, which fails because there is no file called jsf.jar at any location in the repository. This doesn't happen with subprojects that only produce jar files, so it's something to do with the war plugin specifically. |
| Comments |
| Comment by Spencer Allain [ 12/Oct/09 ] |
|
I should mention that it "works" eventually. Do a clean checkout of the project source (with no .gradle directories in existence yet): gradle clean war [Fails] Somehow the cache gets into a state where it works any time after the first failure, but fails during the first compilation attempt, or any time the cache is forced into a rebuild state. |
| Comment by Spencer Allain [ 14/Oct/09 ] |
|
This is a zip file of a very simplistic multi-project build that demonstrates the issue. |
| Comment by Spencer Allain [ 15/Oct/09 ] |
|
So... the only workaround that I've found is to either explicitly exclude the modules with explicit artifacts or have proj2 have an explicit "compile" dependency on for any "compile/runtime" dependency from proj1 (creating a "runtime" dependency on proj2 for things that are "runtime" dependencies on proj1 still fail to resolve) It also seems to be a problem regardless of whether proj1 uses the war plugin or not (meaning that it's something strictly to do with proj2 using the war plugin, and transient dependencies with explicit artifacts, and not some interaction between war plugins) |
| Comment by Spencer Allain [ 08/Feb/10 ] |
|
Using the latest snapshot release of 0.9, this appears to no longer be an issue, and probably should be closed. |