https://gradle.com/ logo
Join Slack
Powered by
This message was deleted.
# plugin-development
s
This message was deleted.
🧵 1
s
Sorry if I was not clear. The question is not so much about Task versus doLast; those were just things I tried. The question is about how to apply bytecode enhancement to compiled classes and still allow up-to-date handling to work properly. Task, doLast, etc - don't care
Of course I can write the enhanced classes to a directory other than the compile output; but thats not user-friendly
And I realize it is not trivial. But from the perspective of a user, its just not friendly to force them to now reconfigure "downstream tasks" that rely on the compiled classes (Jar e.g.)
Besides layering multiple enhancers over the same class is generally asking for problems anyway
e
(but they're moving towards a compiler plugin instead of bytecode manipulation)
on Android, there's already a system set up to register bytecode transformations, https://developer.android.com/reference/tools/gradle-api/7.2/com/android/build/api/instrumentation/AsmClassVisitorFactory but that's not really applicable to non-Android projects
you could take inspiration from that, and register as an artifact transformation, but it would require re-wiring or creating new run/test tasks and publications to make use of it
s
Thanks @ephemient - I have to support runtime enhancement as well and really do not want to duplicate effort for 2 distinct ways to do the "enhancement". Otherwise a compiler plugin would be better
x
I believe that Gradle snapshots the task output after all its actions have run (so after all 
doLast
, so in that sense, up-to-date would still work. but then you are going to have problem supporting the other incremental feature (ie running the action incrementally).
s
This was what I wondered when I asked about doLast. I'll play around and see. WDYM "running the action incrementally"? Do you mean just when it "needs to be run"? I would think asking the compile task if it did work would suffice?
For the historical record, doLast does have the effect I wanted.
I do miss out on the ability to use `@Incremental`on my enhancement process, but 🤷🏼
Not yet sure if it introduces the same limitation to the compile task
x
By "running the action incrementally" I mean using the mechanism that allows Gradle to send the task action the list of input files that are added/changed/removed so that the action can process only these instead of all the inputs (which is basically 
@Incremental
). Not using this means you have to revisit all the 
class
file and is going to be much slower.
s
Yep, that's what I noted above
Thanks for following up
Just not a silver bullet here
Have to pick your poison
To me, not having to re-wire down stream tasks was worth the trade off
ymmv ofc
x
yeah that's fair. we're adding API to help with that in the Android plugin but I would love to see something similar in the rest of the ecosystem (starting with Gradle's core plugins)
s
Yeah it would have been wonderful to have the finaizer task approach (as an option at least) work the same
Most JPA domain models are not huge so hopefully its not a terrible situation
Open in Slack
PreviousNext
Powered by