After renaming a package the resulting jar contains both versions of the package and class files

Old Forum Archive
1

similar to the post http://forums.gradle.org/gradle/topics/after_renaming_a_class_the_subsequently_created_jar_contains_both_versions_of_the_class I had this problem for quite some time, but stumbled upon it again with a new employee that did not know the trick to delete destinationDir in JavaCompile.doFirst.

Here is what we do:

the simplest java project with one Java Sourcefile in a package “test1”. build.gradle only contains “apply plugin: ‘java’”. I run “gradlew jar”. Then I rename the package “test1” to “test2” and also adapt the Java source file to reflect the changed package name A new “gradlew jar” results in a jar file that contains both “test1” and “test2” packages, with the classes inside.

We have had this problems for all the time we are using gradle now (about 2 years), and our standard workaround is

tasks.withType(JavaCompile)*.doFirst {
 delete destinationDir
}

BTW: If I only rename the class and not the package, everything works as expected, only the new class is in build/classes and in the jar file. But as soon as I change the package name, I have both versions in the jar file.

2

Cannot reproduce. After renaming the package and rerunning ‘gradle jar’, the new Jar still contains a ‘test1’ directory (which isn’t perfect), but it’s empty. Knowing the current implementation, this is the result I would expect.

3

Hi Ronald,

I have been unable to reproduce your issue with the instructions you provided. What version of gradle are you using? Just to confirm the old package directory in the jar contains class files and is not empty?

Perryn

4

Yes, you are absolutely right. I did another check and noticed that only the empty directories remain but the classes are removed.

However, we did have this problem in the past, but maybe it has vanished in one of the recent versions. It might also be related to our quite complex build scripts.

Sorry for that, I will try if our build runs stable without those workarounds now.