This message was deleted.

It seems the

INCLUDE

flag works exactly as designed. I'd recommend not to set

duplicatesStrategy

at all but fix the configuration of the

Jar

task to not have errors. Painful as that might be, it's deterministic and will be guaranteed to be correct. IMHO

INCLUDE

was only ever useful as a means of upgrading old builds that didn't need to care about duplicate files (e.g. when they were really identical) without having to fix all task configurations. If you consider ignoring such problems to be "useful"

Oh ok. That's unfortunate. 🙃 So, at the moment I'm extending the consumed files of the existing Jar task with

setFrom

and pass the directory with instrumented classes. What would be the most reliable way to exclude existing duplicates of non-instrumented content?

IMO the most reliable way would be to create a separate Jar task with only the inputs you want

I don't think that will help him, as he is working on a plugin that does this, so it needs to work generically iirc 🙂

oh. the kotlinx.atomicfu used to do this hack where they swapped the sourceset outputs so that consumers only saw the post-processed classes, but that technique is kinda iffy…

I still have to rely on

"jar"

task as it's often extended by users to provide additional content to the final package. This task also collects every classes that are supposed to be bundled (I don't know if that's Java, Kotlin, or any other JVM-based language) so I'm attaching my instrumentation task to the source set with

sourceSet.compiledBy(instrumentTaskProvider)

and then passing its output to the Jar task. And at this point, classes get duplicated and shadowed. Basically, everything's fine but JRE reads first occurrences of the given classes (the shadowed one) instead of what we eventually see when reading jar archive (shadowing ones, instrumented content).

https://github.com/Kotlin/kotlinx-atomicfu/blob/ea661bc5aecdcd3a0a19c3f1c4faf4f39d4fac08/atomicfu-gradle-plugin/src/main/kotlin/kotlinx/atomicfu/plugin/gradle/AtomicFUGradlePlugin.kt#L222 the hack

Basically, I'm running away from the

doLast

approach which isn't configuration-cache-friendly

doLast

per se is not CC unfriendly 😄 But changing the configuration like that sounds pretty hacky and fragile even without CC 😄

It is, but as we spoke — instrumentation is painful 😢 And as I'm obliged to keep that alive, I must bypass it. The jar task approach looks like the lesser evil here.