On 27/06/2013, at 9:34 AM, Adam Murdoch <[email protected]> wrote:
> > 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, One question is how to implement this efficiently. What's interesting here is the information we'd use to detect identical entries happens to be exactly the same information we'll need to provide accurate incremental builds for the copy tasks. So, I think we'll want some way to get at whatever information the up-to-date checks used to make the decision. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
