[GRADLE-1678] When using daemon, Zip task creates archive into ~/.gradle when destinationDir is not set Created: 19/Jul/11 Updated: 04/Jan/13 Resolved: 30/Sep/11 |
|
| Status: | Resolved |
| Project: | Gradle |
| Affects Version/s: | 1.0-milestone-3 |
| Fix Version/s: | 1.0-milestone-5 |
| Type: | Bug | ||
| Reporter: | Daz DeBoer | Assignee: | Unassigned |
| Resolution: | Fixed | Votes: | 0 |
| Description |
|
If the 'destinationDir' property is omitted from a Zip task, and running the daemon, the archive is created into ~/.gradle, even though ZipTask.outputs.files reports that the archive will be created in the project directory. This is likely due to bug: http://issues.gradle.org/browse/GRADLE-1249, combined with the default behaviour when no destinationDir is specified. Strange behaviour ensues with up-to-date checking, presumably due to the fact that the reported output file (not the actual output file) is used for checking. |
| Comments |
| Comment by Tim Berglund [ 19/Jul/11 ] |
|
Is it the case that AbstractArchiveTasks do not have a default destinationDir value? It looks like it's null if nobody ever calls the setter, in which case the File constructor call in getArchivePath() will default to the working directory. I'm not totally sure where to go inside the Task API to get the projectDir (ProjectInternal? FileResolver?), but it seems like that would be a tight, non-daemon-oriented solution to this, respecting the enduring importance of |
| Comment by Daz DeBoer [ 19/Jul/11 ] |
|
The BasePlugin configures all AbstractArchiveTasks by convention, with the default value for destinationDir being build/distributions. Without the BasePlugin applied, no convention gets applied, and you end up with a null value for destinationDir. This would be fine, except that when running with the daemon, new File(null, "archive") creates the file in ~/.gradle - this is due to This bug would be fixed by simply adding:
public File getDestinationDir() {
return destinationDir != null ? destinationDir : getProject().getProjectDir();
}
But I'm not convinced we want to start adding default values in an adhoc manner. |