You need this:

task cleanTempDir(type: Delete) {
delete fileTree(dir: "tempDir", exclude: "dont_delete.txt")
}

Hi Luke,

That's cleaner syntax, but it still has the same behavior as my solution ... the directories are still left behind.

Even this example (without an exclude) still leaves empty directories behind:

task cleanTempDir(type: Delete) {
delete fileTree(dir: "tempDir")
}

I need both directories and files deleted.

I actually can't see a way to do this. Let's come at it a different direction.

Why do you need to delete a tree except for some files?

This is a script for deploying artifacts on a remote user's system. FYI, I'm mimicking an existing (brittle) Ant build, and am constrained by how much logic I can change w/o introducing risk.

The directory in question contains a mix of both source and content. The source directories need to be deleted and redeployed to, whereas the content directories are quite large and need to be left alone. Something like this:

/dirToDelete/a – source files, should be deleted
/dirToDelete/b – content files, should NOT be deleted
/dirToDelete/c – content files, should NOT be deleted
/dirToDelete/d – source files, should be deleted

Now I could write a script such that it specifically deletes "a" and "d", but I'd like to avoid having to modify the script if we happen to add an "e" directory. Ant supports [1]this like so:

<delete>
<fileset dir="/dirToDelete">
<exclude name= "b/*" />
<exclude name= "c/*" />
</fileset>
</delete>

So ultimately I could just use AntBuilder under the hood. But it seems like this is a reasonable feature for Gradle to support.
----------------------------------------------------------------------------------------
[1] https://ant.apache.org/manual/Tasks/delete.html

Please provide an elegant solution to this.

Also, a wildcard support would be perfect.

delete 'somepath/somefil*.txt'

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.