Open funkrusher opened 1 year ago
+1
Not sure if I'm on the same page here, but does this means that, if implemented, there could be an option to generate all jOOQ
-related classes without the need to re-declare some dependencies, plugins, and such in a Quarkus
project, right?
Not sure if I'm on the same page here, but does this means that, if implemented, there could be an option to generate all
jOOQ
-related classes without the need to re-declare some dependencies, plugins, and such in aQuarkus
project, right?
yes,
but as you say:
But because of that, the quarkus-jooq dependency would become bigger (in size) for all users (even those that do not need the Jooq-Codegen.
But for me this would be ok.
For me it would also be ok, if i declare the dependencies separately in addition to "quarkus-jooq", but those dependencies should then have the same jooq-version as the jooq-version given in the quarkus-jooq version. It would be a bit of a hassle to set those versions manually.
Would it be possible to set the desired jooq-version from the outside?
I don't fully understand why code-gen (and friends) should be in the same io.quarkiverse.jooq:quarkus-jooq
group...but I'm far from being an advanced jOOQ
user.
I was more thinking about something like, hypothetically, io.quarkiverse.jooq:quarkus-jooq-codegen
. Plugging that one into a different (Gradle
/ Maven
) scope could offer a task to generate the jOOQ
classes by hopefully recognizing automatically the configured datasource, and perhaps even taking into consideration Flyway
or Liquibase
lifecycles, and things like that.
Probably too much for this extension :smirk: ...but currently integrating the code generation part, which is crucial, does not understand anything-Quarkus
, so in my case, I have to re-declare dependencies and do a whole lot of Jiu Jitsu to make it work — then again, that has nothing to do with this extension, which works like a charm for me :1st_place_medal:
@x80486
this sounds like a good idea, having a separate "quarkus-jooq-codegen" plugin.
I just want to say...
i often need to be able to customize:
if other people do not have those requirements and are able to use "quarkus-jooq" out of the box, it is ok for me too. I just will not be able to use the "quarkus-jooq" plugin then, which could provide a helpful UI/UX to me where i can see and manage my quarkus-database source.
My ideal solution would be, that i can use the "quarkus-jooq" plugin, but still be able to do all my customizations.
But i have no good knowledge about the Quarkus-Extenstions, so i don't know what could be the best way here.
Hello,
i have developed myself a small testproject for using jooq with quarkus and make use of the jooq-codegenerator and also jooq-meta in this project:
I would like to use your quarkus extension, to use jooq, but it seems that it only provides the main jooq library, but not any of the other ones (meta, codegen, ..?). Am i correct here? Especially the codegen is important to me, as its kind of a core-feature of jooq i think.
And it also may seem helpful to be able to select the jooq-version that one wants to include, because jooq has a version-matrix for supported database per jooq-version, so if you only provide the latest jooq-version, developers would not be able to go with an older version if they still use an older database. Am i correct here?:
what would also be helpful is, to be able to create a Configuration that is dependent on some input parameters (clientId). For example:
JooqExecuteListener
that appends a clientId=X clause after every statement automatically throught the app. But thats only possible if you are creating the Configuration with input-parameters. It seems to me, that the Factory you provide can only be configured without such rest-request specific input-parameters.sorry, it got a bit long :)
More or less, i would say that it would seem to me most beneficial, if i have full control over the jooq dependencies and the versions they have, while still having jooq available in the quarkus dev-tools for example for some helpful info and tooling, so that i have a benefit over just using jooq as direct library-dependency.