Closed shorn closed 10 months ago
For myself, some reasons for me to stay with this plugin:
First, let me say thank you for all your hard work on this plugin.
Thank you. I appreciate this rare type of feedback.
What are the plans for your plugin in the face of this new built-in plugin?
I see that you've released new versions of the plugin which resolve the Gradle 8.5 deprecation issues - this implies you are not abandoning the plug-in just because a new one exists (once again: thank you).
If you plan to continue work on this plug-in - it would be good to outline for users why they should use this or the official plugin. If folks have no criteria to choose - they'll obviously choose the official built-in plugin.
See my comment on a related issue.
For myself, since it appears that support is ongoing - I'm staying using this plugin for the moment, because I don't want to spend the time to migrate to the official plugin. Also because I don't want to be surprised by finding out the official plugin does things very differently to this one.
If you think there are benefits to this plugin over the official, it might make sense to add some migration documentation for folks on how to migrate from the official plugin to this plugin (and maybe the other direction too).
It's not my goal to keep, increase, or maximize the user base of the gradle-jooq-plugin
. If users are happy with the plugin, great. If users are not happy with it, they can pick another plugin or write one themselves. The last thing I want is any contention and debate with users and plugin authors over what plugin "is better than the other".
What I believe is a strong suit of my gradle-jooq-plugin
is its maturity of seven years of development, maintenance, support, and real-world-usage and its idiomatic usage of many Gradle features. That might be a good reason for users to leverage this plugin, or different criteria might be more important for users to use another plugin.
First, let me say thank you for all your hard work on this plugin.
As of version 3.19, jOOQ has an official Gradle plug-in: https://www.jooq.org/doc/3.19/manual/code-generation/codegen-gradle/
What are the plans for your plugin in the face of this new built-in plugin?
I see that you've released new versions of the plugin which resolve the Gradle 8.5 deprecation issues - this implies you are not abandoning the plug-in just because a new one exists (once again: thank you).
If you plan to continue work on this plug-in - it would be good to outline for users why they should use this or the official plugin. If folks have no criteria to choose - they'll obviously choose the official built-in plugin.
For myself, since it appears that support is ongoing - I'm staying using this plugin for the moment, because I don't want to spend the time to migrate to the official plugin. Also because I don't want to be surprised by finding out the official plugin does things very differently to this one.
If you think there are benefits to this plugin over the official, it might make sense to add some migration documentation for folks on how to migrate from the official plugin to this plugin (and maybe the other direction too).