Why does gradle-1.7-all.zip contain four different files with the same name?

I downloaded gradle-1.7-all.zip (sha1sum 0b0fbedd02a2f70c51ae2732889bfeed828d7afb), and proceeded to unzip it. This is on Ubuntu 10.04 with the standard “unzip” command:

ppelletier@chives:~/Development$ uname -a

Linux chives 2.6.32-34-generic #77-Ubuntu SMP Tue Sep 13 19:39:17 UTC 2011 x86_64 GNU/Linux

ppelletier@chives:~/Development$ unzip -v

UnZip 6.00 of 20 April 2009, by Debian. Original by Info-ZIP.

Latest sources and executables are at ftp://ftp.info-zip.org/pub/infozip/ ;

see ftp://ftp.info-zip.org/pub/infozip/UnZip.html for other sites.

Compiled with gcc 4.4.3 for Unix (Linux ELF) on Mar 7 2010.

UnZip special compilation options:

ACORN_FTYPE_NFS

COPYRIGHT_CLEAN (PKZIP 0.9x unreducing method not supported)

SET_DIR_ATTRIB

SYMLINKS (symbolic links supported, if RTL and file system permit)

TIMESTAMP

UNIXBACKUP

USE_EF_UT_TIME

USE_UNSHRINK (PKZIP/Zip 1.x unshrinking method supported)

USE_DEFLATE64 (PKZIP 4.x Deflate64™ supported)

UNICODE_SUPPORT [wide-chars, char coding: UTF-8] (handle UTF-8 paths)

LARGE_FILE_SUPPORT (large files over 2 GiB supported)

ZIP64_SUPPORT (archives using Zip64 for large files supported)

USE_BZIP2 (PKZIP 4.6+, using bzip2 lib version 1.0.5, 10-Dec-2007)

VMS_TEXT_CONV

WILD_STOP_AT_DIR

[decryption, version 2.11 of 05 Jan 2007]

UnZip and ZipInfo environment options:

UNZIP: [none]

UNZIPOPT: [none]

ZIPINFO: [none]

ZIPINFOOPT: [none]

ppelletier@chives:~/Development$

When I unzip it, I get three prompts from unzip of the form:

replace gradle-1.7/src/META-INF/services/org.gradle.configuration.project.ProjectConfigureAction? [y]es, [n]o, [A]ll, [N]one, [r]ename:

and indeed, it turns out that the zip file appears to contain four different files (with different lengths; i. e. it’s not four identical copies) all with the same name, so the last three attempt to overwrite the first one as the zipfile is unpacked.

ppelletier@chives:~/Development$ unzip -l gradle-1.7-all.zip | fgrep gradle-1.7/src/META-INF/services/org.gradle.configuration.project.ProjectConfigureAction

89 2013-08-06 12:47

gradle-1.7/src/META-INF/services/org.gradle.configuration.project.ProjectConfigureAction

133 2013-08-06 12:47

gradle-1.7/src/META-INF/services/org.gradle.configuration.project.ProjectConfigureAction

56 2013-08-06 12:47

gradle-1.7/src/META-INF/services/org.gradle.configuration.project.ProjectConfigureAction

65 2013-08-06 12:47

gradle-1.7/src/META-INF/services/org.gradle.configuration.project.ProjectConfigureAction

ppelletier@chives:~/Development$

I’m hoping/assuming I can just ignore this, since it’s in the source, and not the binaries. But still, it’s a bad out-of-the-box user experience, and it would be nice if you could avoid this, or at least warn about it in the installation instructions. Or am I doing something wrong somehow?

It’s a known (packaging) bug and fixed in 1.8. You can ignore the duplicates.

3 days ago when I built the release branch, the same problem was present in “-all.zip” for some files.

I believe this is still an issue in 1.8. Here are the errors/warnings I get when using UnZip 5.51 of 22 May 2004, by Info-ZIP to extract gradle-1.8-all.zip:

  replace gradle-1.8/src/META-INF/services/org.gradle.configuration.project.ProjectConfigureAction? [y]es, [n]o, [A]ll, [N]one, [r]ename:  replace gradle-1.8/src/META-INF/services/org.gradle.configuration.project.ProjectConfigureAction? [y]es, [n]o, [A]ll, [N]one, [r]ename:  replace gradle-1.8/src/META-INF/services/org.gradle.configuration.project.ProjectConfigureAction? [y]es, [n]o, [A]ll, [N]one, [r]ename:  

The fix exists on master but didn’t make it into 1.8.