Replies: 3 comments 1 reply
-
@jeffgbutler Thoughts here as this would be most impactful to you :) Just a general discussion... |
Beta Was this translation helpful? Give feedback.
-
I've thought about this off and on over the years. I always come back to leaving it alone because of the work involved, and some other issues too... With the Maven plugin, there's not a lot stopping us from breaking it out. I originally wrote it so that I could use it in the test projects and it made sense to have it integrated because of consistent versioning. For me, that's still how I use it the most and I would need to think about how to do testing and debug if it were separate. It would also increase the toil of a release because now there would be two separate releases - one for core, and another for Maven. It hasn't changed much over the years - although I am working on some updates right now to support toolchains - which is more complex than I originally hoped for. Eclipse has other issues. The process for creating the eclipse plugin actually copies source code and recompiles it in the plugin build process. It also copies the doc pages into the eclipse doc plugin. Having the projects together makes that easier. I'm sure there's a way to copy the docs directly out of GitHub so that could likely be overcome. Same with source code - although I must admit that the recompile is a real kludge and I always want to remove that. But it's not so easy to automate the making of an eclipse plugin and source plugin from a Maven artifact. This project (https://github.com/eclipse/ebr) claims to have a solution, but I've not spent a lot of time on it so far. Honestly, there is not much change in the generator these days so it may not be worth any of this trouble. I'm not making any updates to the legacy code generators. The new code generators offload most of the work to MyBatis Dynamic SQL and generate very minimal code. I think I have about 5-6 minor changes I'll be making for the next release of the generator - and it's been almost a year since the last release. By far, the most toil in a release of the generator is related to the Eclipse feature. There is a lot of manual work needed for that and I But I digress. Bottom line is that I'm open to breaking the Maven plugin out, but not until after the next release because I'm in the middle of some updates right now. Eclipse is more of a problem - as aways ;) |
Beta Was this translation helpful? Give feedback.
-
I loved Eclipse for a long time. But now I love Kotlin more than Java, and Kotlin means IntelliJ :) You can see install metrics in the Eclipse marketplace: https://marketplace.eclipse.org/metrics/successful_installs/alltime |
Beta Was this translation helpful? Give feedback.
-
Currently today this project has a lot going on. My initial thinking is that Maven plugin should be split out so it can independently get released more easily and more often align around maven work itself rather than just when needed with generator. We already do this today with the migrations maven plugin. However, also thinking there is quite a bit going on here in general and Eclipse could use the same idea. Given this is a chore to do but think in long term it may be a better idea and certainly not something needed anytime soon.
Thoughts?
Beta Was this translation helpful? Give feedback.
All reactions