What is happening is that a filtered view of sourceFiles is being set up as a task output and then a configuration is being added to sourceFiles. This is then causing an issue in Gradle because it ends up trying to resolve the dependencies in this configuration to determine the task outputs at a time when a deadlock is possible. We are making a change in Gradle so that this situation is identified and we throw an error rather than allowing the deadlock, but I wanted to follow up as I think there are probably some improvements that can be made to this plugin.
I might be misunderstanding the intent here, but it does not seem correct that getByPassedArchives() should be an output of this task. Task outputs should represent the things that the task produces. This value seems to represent inputs of the task that have not been included in the resulting archive. Since the task does not actually affect these files, they should not be a task output. In fact, it seems like instead the archiveBypasses and archiveExcludes properties should be input properties of this task to ensure proper incremental behavior.
Of course, there may be something here that I don't understand - if you feel like the way this task is implemented is correct, I'd love to dig into the use case to better understand it. In any event, at the moment, this task implementation will need to be updated to be compatible with 4.0 (resolving a configuration as part of a task output will now result in an error).
I wanted to raise this to your attention as an issue was raised on Gradle about a failure when using the 'org.anarres.jarjar' plugin.
The root cause of the issue seems to be the specification here: https://github.com/shevek/jarjar/blob/master/jarjar-gradle/src/main/java/org/anarres/gradle/plugin/jarjar/JarjarTask.java#L154
What is happening is that a filtered view of
sourceFiles
is being set up as a task output and then a configuration is being added tosourceFiles
. This is then causing an issue in Gradle because it ends up trying to resolve the dependencies in this configuration to determine the task outputs at a time when a deadlock is possible. We are making a change in Gradle so that this situation is identified and we throw an error rather than allowing the deadlock, but I wanted to follow up as I think there are probably some improvements that can be made to this plugin.I might be misunderstanding the intent here, but it does not seem correct that
getByPassedArchives()
should be an output of this task. Task outputs should represent the things that the task produces. This value seems to represent inputs of the task that have not been included in the resulting archive. Since the task does not actually affect these files, they should not be a task output. In fact, it seems like instead thearchiveBypasses
andarchiveExcludes
properties should be input properties of this task to ensure proper incremental behavior.Of course, there may be something here that I don't understand - if you feel like the way this task is implemented is correct, I'd love to dig into the use case to better understand it. In any event, at the moment, this task implementation will need to be updated to be compatible with 4.0 (resolving a configuration as part of a task output will now result in an error).