https://kotlinlang.org logo
Title
b

bamboo

02/24/2017, 10:09 PM
In any case, it’s better to avoid changing files in-place
o

oehme

02/27/2017, 10:25 AM
bamboo: It’s totally reasonable to change them in a
doLast()
block.
b

bamboo

02/27/2017, 11:31 AM
Ok, I guess as long as all the weaver inputs are contained in the compile task inputs nothing bad would happen
I also wonder how weaving in-place will interact with incremental compilation
o

oehme

02/27/2017, 5:37 PM
You can add more inputs by calling task.inputs
Incremental compilation would not be affected, because weaving does not take part in the compilation itself like annotation processors do (i.e. it can’t introduce new APIs that the user could call)
b

bamboo

02/27/2017, 5:38 PM
But the weaver would have to be idempotent, right?
Or incremental
o

oehme

02/27/2017, 5:39 PM
Idempotent for sure, yes
Long-term we could make this a first-class citizen by having a task dedicated to weaving where people can plugin all their bytecode fiddling tools
That would also solve incrementalism nicely
Unfortunately the way the Java plugin is currently set up (with lots of plugins depending on the value
JavaCompile.destinationDir
), doing this yourself is painful, because you have to fix up every plugin that uses this value.
If
JavaCompile
had its own
destinationDir
and nobody directly depended on that, but only on
output.classesDir
, then the
classes
task could do a copy+weave.