[GRADLE-2825] Duplicate file deprecation warning issued even when strategy is set to include Created: 04/Jul/13  Updated: 24/Jul/13  Resolved: 24/Jul/13

Status: Resolved
Project: Gradle
Affects Version/s: 1.7-rc-1
Fix Version/s: 1.7-rc-2

Type: Bug
Reporter: Luke Daley Assignee: Unassigned
Resolution: Fixed Votes: 0

Comment by Adam Murdoch [ 16/Jul/13 ]

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'.

Comment by Luke Daley [ 16/Jul/13 ]

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


Comment by Adam Murdoch [ 17/Jul/13 ]

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.

Comment by Luke Daley [ 17/Jul/13 ]

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?

Comment by Adam Murdoch [ 17/Jul/13 ]

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

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