On 26/06/2013, at 11:12 PM, Luke Daley <[email protected]> wrote:
> Coming from this post: > http://forums.gradle.org/gradle/topics/gradle_doing_weird_things_duplicating_files_on_jar > > I wonder if with the new duplicate archive entry stuff we should offer an > option to just silently “merge” identical entries (in terms of final path and > content). One complication is that this is not mutually exclusive to the > other strategies. This might be what you're saying already: I think the entries that we're currently calling 'duplicates' can fall into 2 categories: - Entries that are identical as far as the target container is concerned, so that they have the same path, same content and same meta-data. For example, if we're copying to, say, a linux file system, then two entries are identical if they have the same path, content, permissions and timestamp. - Entries that are not identical, but conflict with each other. Whether two entries conflict depends on what it is that the container represents. For example, two (non-identical) Jar entries with path 'META-INF/MANIFEST.MF' conflict with each other, whereas two (non-identical) Jar entries with path 'META-INF/services/my.service' do not conflict with each other (usually). For identical entries, we can probably just always discard them, and we could probably make this change now, even though it is strictly a breaking change. Maybe we add some way to switch back to the old behaviour, maybe not. For conflicting entries, there are a couple of aspect: First, how to decide whether 2 entries conflict with each other, and secondly, what to do with them. In principle, any attribute of the entry or its content could imply a conflict, and for some types of conflicts the path of the entry is not relevant. But I think it's probably reasonable to use only the path for conflict detection - anything else you should be able to code up yourself with `eachFile()`. A simple approach is to assume that two non-identical entries with the same path always conflict, which is what we've gone with initially. We work around the cases where that assumption doesn't hold by letting you tweak what to do with the conflicting entries. But perhaps we want to separate these, so that there's separate strategies for detecting conflicts and for what to do with them. I think this might better allow us to introduce container-specific rules about what constitutes a conflict. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
