> hopefully also avoiding copy-and-paste code...), then the extension
> function could be in a separate package, and indeed a separate project
Sure, I understand the drawback of copy pasting, but that could be a viable
workaround for the time being. Thanks for documenting it.
> Or, if there isn't an option to use public types, could *gasp* actually
> use JPMS to expose the org.jooq.impl package to
> org.jooq.kotlin_stuff_goes_here. Mark Reinhold would be so happy.
I'm not touching JPMS anytime soon during the next year. Making jOOQ a
module provides almost zero value to the community right now (as JPMS
adoption is still incredibly low), while causing tons of headaches for us,
with IDEs and transitive dependencies still not being 100% ready for it.
Anyway, I wonder if we could simply include that Kotlin class in the jOOQ
library directly, instead of putting it in a new module... If our mostly
Java based integration tests don't fail because of some class loading
issue, I don't see a problem adding some Kotlin classes to org.jooq.impl.
I've created an issue for this: https://github.com/jOOQ/jOOQ/issues/9335
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to [hidden email].