Having the same problem. When you go to unzip it, it'll try to overwrite the duplicate file with itself over again.

The Jar and Zip tasks suffer from the same defect.

Having a web project that simply acts as a collector for some other web projects, I've merged them with no duplicates redefining the war task to use ant.zip with the duplicate attibute set to 'preserve'.

apply plugin: 'war'

jar.enabled = true

dependsOn (':webprj1')
dependsOn (':webprj2')

def warPath = project.war.archivePath

task war(overwrite: true) << {
	ant.zip(destfile: warPath, duplicate: 'preserve', keepcompression: true) {
		project.dependsOnProjects.each {prj->
			zipfileset (src: prj.war.archivePath)
		}
	}
}

I found this defect from the discussion http://gradle.1045684.n5.nabble.com/War-dependency-to-another-war-td4257270.html. The workaround mentioned in this thread is:

war {
    into("/") {
        exclude 'META-INF/MANIFEST.MF' // or whatever
        with project(':common').war
    }
}

Unfortunately, I still get two MANIFEST.MF files using this code. Does anyone know a better workaround?

Here's what I came up with to insert the contents of one WAR into another, excluding duplicates:

def warPath = project.war.archivePath
war << {
	ant.zip(destfile: warPath, duplicate: 'preserve', keepcompression: true, update: true) {
		zipfileset (src: project(':common').war.archivePath)
	}
}

Thanks, Davide, for the example.

Does anyone know of a better workaround?

Since the war task extends the jar task which extends the zip task, I reckon this is similar to GRADLE-1050 and GRADLE-2171. There might be more issues as well. Developers, please consolidate all these issues into one so we all can vote for it, thank you.

If the problem is duplicate jar files in WEB-INF/lib, then the following might help:

war { 
    def originalClasspath = classpath 
    // Restrict the classpath to files with unique names 
    classpath = files { 
        def uniqueFiles = [] 
        originalClasspath.each { input -> 
            if (uniqueFiles.find({it.name == input.name }) == null) { 
                uniqueFiles << input 
            } 
        } 
        return uniqueFiles 
    } 
}

And a more solid plugin-based workaround:

subprojects {
apply plugin: WarTweaker
}

class WarTweaker implements Plugin<Project> {
    void apply(Project project) {
        project.tasks.withType(War) { task -> 
            task.doFirst({
                println "Removing duplicates from classpath of $task"
                def originalClasspath = task.classpath
                // Restrict the classpath to files with unique names 
                task.classpath = project.files { 
                    def uniqueFiles = []
                    originalClasspath.each { input -> 
                        if (uniqueFiles.find({ it.name == input.name }) == null) { 
                            uniqueFiles << input 
                        } 
                    }
                    return uniqueFiles 
                } 
            })
        }
    }
}

@Daz the plugin-based solution is very cool!

the plugin doesn't get rid of the duplicate manifest file

Seemingly related to issues #710 and #934.

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

The use case should be solvable with AbstractCopyTask.setDuplicatesStrategy(DuplicatesStrategy). Please open an issue on GitHub in case you find that your use case still isn't fulfilled.