[GRADLE-1883] Provide a way to disable the default excludes on a FileTree without disabling the global excludes for all PatternSet instances Created: 01/Nov/11  Updated: 07/Feb/17  Resolved: 07/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-5
Fix Version/s: None

Type: Improvement
Reporter: Mauro Molinari Assignee: Unassigned
Resolution: Duplicate Votes: 9


As discussed at: http://forums.gradle.org/gradle/topics/filetree_and_default_excludes

The FileTree is currently using some default exclusion patterns like Ant does. This is not well documented (I couldn't find anything about this in the user guide and the Javadoc doesn't help either). Anyway, I miss the possibility to disable such default exclusion patterns on a specific FileTree instance, just like Ant does.

In fact, invoking "patterns.globalExcludes = []" on a ConfigurableFileTree instance will actually disable such exclusions on ALL the PatternSet instances created, because globalExcludes points to a static variable.

Comment by Björn Kautler [ 14/Jul/14 ]

There is a per-task work-around, as the Ants default excludes (not only like them, but literally) are used, you can manipulate them like the following:

import org.apache.tools.ant.DirectoryScanner
task makeZip(type: Zip) {
   doFirst {
      DirectoryScanner.defaultExcludes.each { DirectoryScanner.removeDefaultExclude it }
      DirectoryScanner.addDefaultExclude 'something has to be in here or everything gets excluded'

   baseName 'test'
   from 'test'

   doLast {

It could be improved by storing the defaults before and restoring them afterwards and similar stuff of course. This is just for proof of concept. This worked with a .gitignore in the test directory.

It could of course cause problems like if the defaults were modified before and they get reset to default (one could save the state and restore it exactly) or if the copy fails and --continue is used, the defaults are changed for other tasks that follow (maybe using event listeners to reset the defaults could be used to fix this), or if you use --parallel you could influence other tasks (I guess here nothing can be improved than not to use --parallel).

Comment by Björn Kautler [ 14/Jul/14 ]

Of course the ant task DefaultExcludes could also be used to manipluate the default excludes list, as could the ant.zip task be used which supports the defaultExcludes: 'no' property

Comment by Geoff Granum [ 08/Mar/16 ]

This behaviour violates the principle of least surprise, and compounds the surprise by failing to even notify that files are going to be skipped. I realize it's basically impossible to push out a new release that disables this behaviour, but the fact that it's not even mentioned in the docs for the copy spec is kind of brutal, for those of us who stumble into it!

Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Mauro Molinari [ 15/Nov/16 ]

Unless otherwise advised, I think this is still an issue in recent Gradle.

Comment by Benjamin Muschko [ 07/Feb/17 ]

The work is now tracked here: https://github.com/gradle/gradle/issues/1348

Generated at Wed Jun 30 12:06:56 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.