That's the whole point. In 2.0 it will be an error to copy duplicate files into a destination that doesn't support duplicate files, such as into a file system directory. It'll still be an error whether you set the strategy to include or don't set the strategy. The warning is telling you 'this copy operation will fail in Gradle 2.0, you need to do something about it'.

Seems it would be better to error if you set include then, rather than waiting to fail. Also, the 'include' option does give you a last-wins strategy, which may be valid.

So for 1.7, do you want to change it to:

1. Log when trying to include duplicate in something that supports duplicates with no strategy set
2. Log when trying to include duplicate in something that doesn't support duplicates regardless of strategy

?

It might be an option to fail early when you set the strategy to 'include', but only if we know that the copy spec is going to be used to copy to the file system.

As far as last-wins goes, I think we should make that a separate option. The idea is that a copy spec should give you the same result regardless of container, and right now 'include' gives you last-wins when copying to a directory and all when copying to an archive.

I think we were a bit eager with the warning, as you can only get rid of it using an incubating feature, and it would make sense to add filtering for identical files first. So, I reckon for 1.7 let's just get rid of the warning.

We actually removed the deprecation message and added info logging.

Do you want to use the when-to-log I outlined above with info logging? Or just remove the logging entirely?

We're effectively undeprecating the behaviour for now, so I'd get rid of the logging too.