After renaming a class the subsequently created jar contains both versions of the class


(rhuberg) #1

Performing the following steps yields a jar with 2 versions of a class (old name and new name); this forces me to clean. Is it expected that we clean when doing this type of refactoring. Can gradle delete the classes directory when it knows its recompiling? 1. gradlew clean jar 2. rename a class 3. gradlew jar The build/classes/…/package-name directory contains both the old compiled class (old name) and the newly compiled class (after the rename); and therefore, so does the build/libs/project-SNAPSHOT.jar. This seems more on an issue in our automated build environments, where we want to avoid rebuilds. In these cases it is not obvious when to clean or NOT - unless we clean nightly or some other scheduled clean.


(Peter Niederwieser) #2

This shouldn’t happen as every compile deletes the class files it generated on the previous run.


(rhuberg) #3

We have a AspectJ task that is overriding the Java compile. It it calling deleteAllActions() (see below). Would this explain why the clean of the build/classes directory did NOT happen? It seems to.

def configureAspectJCompile(task, sourceSet) {

configure(task) {

source = sourceSet.allSource.matching {

include ‘**/*.aj’

include ‘**/*.java’

}

deleteAllActions()

doFirst {

ant {

taskdef(resource:“org/aspectj/tools/ant/taskdefs/aspectjTaskdefs.properties”, classpath: configurations.aspectj.asPath)

iajc(


(rhuberg) #4

It is likely that our aspectj plugin originated from a variant of -> https://github.com/ultraq/gradle-support/blob/master/aspectj.gradle


(Peter Niederwieser) #5

Yes, that explains it.


(rhuberg) #6

To complete the dialog…

Referring to the “compileJava.deleteAllActions()” line in “https://github.com/ultraq/gradle-support/blob/master/aspectj.gradle” which was the pattern followed as our aspectj plugin…

After deleting all the actions associated with the JavaCompile task, added an action to delete the classes directory. def configureAspectJCompile(task, sourceSet) {

// Delete all actions related to the Java task that we are replacing

deleteAllActions()

// Recreate the compile related actions

doFirst {

// Delete all previously compiled classes

delete destinationDir

}

doLast {

// Call the AspectJ compiler/weaver

compileAspects(task, sourceSet) // not shown

}

} }

Is there a better way to compile with aspects? Seems awkward to delete the JavaCompile task this way.