In any case, it’s better to avoid changing files i...

# gradle

[bamboo]

In any case, it’s better to avoid changing files in-place

[oehme]

bamboo: It’s totally reasonable to change them in a doLast() block.

[bamboo]

Ok, I guess as long as all the weaver inputs are contained in the compile task inputs nothing bad would happen

[bamboo]

I also wonder how weaving in-place will interact with incremental compilation

[oehme]

You can add more inputs by calling task.inputs

[oehme]

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)

[bamboo]

But the weaver would have to be idempotent, right?

[bamboo]

Or incremental

[oehme]

Idempotent for sure, yes

[oehme]

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

[oehme]

That would also solve incrementalism nicely

[oehme]

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.

[oehme]

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.