Jan Martiska

Exact same use case, exact same problem here.

- Switching to plain Java serialization won't help, that's not supported in native images - I *think* we can't use `@RecomputeFieldValue` substitution for the `SerializableField.fieldOffset` field, because the underlying field...

Hey @stuartwdouglas what would be your suggestion for this please? I suppose we would need to get rid of JBoss Marshalling if we indeed wanted to integrate JBeret into Quarkus?

@stuartwdouglas see https://github.com/jberet/jsr352/blob/master/jberet-core/src/main/java/org/jberet/util/BatchUtil.java#L124 It's used as a general mechanism to clone objects (in particular, the `Job` class that holds a batch job definition)

Yeah, just with this one I'd probably go really lightweight - it's supposed to generate just snippets, not self-contained Java classes, so it could be a script written in Python...

Hmm. Perhaps it is because the gradle plugin project declares its packaging to be `pom` and it should be `jar`? https://github.com/smallrye/smallrye-graphql/blob/1.0.3/tools/gradle-plugin/pom.xml#L15

https://github.com/smallrye/smallrye-graphql/blob/1.0.3/tools/gradle-plugin/pom.xml#L122 This could also be part of the problem?

The Maven plugin generally should work, except of course the serious problem https://github.com/smallrye/smallrye-graphql/issues/1102 that I've just found :) but it works in the sense that it's in public Maven repos...

I remember fixing the client-side counterpart of this just before leaving on PTO. I don't have much insight into how the server side handles generics, I didn't write that relevant...

I meant we might try to use the instrumentation to hook into executions and perform our OpenTracing (and later OpenTelemetry) stuff, as it could be better than "instrumenting" via our...