ppodgorsek commented on PR #94: URL: https://github.com/apache/freemarker/pull/94#issuecomment-1626962891
Thanks for the feedback, @ddekany I'm not sure I understand how you'd like these changes to be incrementally merged. The Jakarta artifacts have been compiled with Java 11 so even separating both wouldn't greatly simplify this PR. The Java upgrade would anyway still require: * JVM Locale changes * RMIC support removal * Ivy configuration updates * Changes in the README I would agree with you about BC once the project uses a "modern" modularised build system such as Gradle, which would allow us to publish two sets of JARs, one with javax and one with jakarta. In the meantime, that's not the case for the `2.3-gae` branch that everyone relies on, and publishing one artifact with both would actually be more of a hassle for the dependency management of projects relying on FreeMarker. You have a point about the versioning, I agree these changes make more sense as part of release 3. I've been a massive supporter of FreeMarker for almost two decades but, having spent the last week trying to perform what I thought would be a very straightforward upgrade, I must admit that keeping BC at all costs is harming this project. From an outside perspective, a lot of the code relies on magic / insider knowledge. 😄 I had to spend a lot of time understanding what the legacy configurations were used for in order to understand what were breaking changes from upgrades such as the JVM rather than simple adjustments. This very steep learning curve makes it very hard for anyone else to contribute, in turn increasing risk if support and maintenance end up being on one person's shoulders only. (yours) The only reason I powered through is because, without Jakarta, FreeMarker is likely to die alone (frameworks such as Spring drive the adoption/decline of many other projects) and that would be a pity. Due to the Jakarta migration, Spring 6 shipped with a very minimalistic version of FreeMarker, which greatly diminishes its value unfortunately. Branch `3` is missing features (from the top of my head `withArgs` is one of them) so even if the git history has diverged, there is still a big risk of breaking backwards compatibility from a feature perspective. FreeMarker being a templating engine, I believe its main focus should be on feature parity/compatibility/BC rather than API BC. Many of the artifacts relying on it on [mvnrepository.com](http://mvnrepository.com/) seem to be packaging it as part of web or email frameworks, without necessarily extending FM capabilities. (admittedly, I haven't checked all of them) From my own experience too, I've never decided to use the FreeMarker JAR because it had that one class that would be so useful on my project. Instead, its value lies in its capabilities. I'll keep this PR open (I'll adjust the version number) and will start packaging and distributing my fork in the meantime, as this will unlock a smoother upgrade to Spring 6 for many projects. I'll continue keeping my fork up to date and will be opening PRs for you as new changes are done on my side. (a wider adoption of Java 5 generics and replacement of a lot of code by standard Apache Commons libraries will be next on my to do list) Java 9 modules will also be a good way to enforce what can be used and extended outside of FreeMarker, this should greatly help with BC of selected parts of the project. I wanted to add a big thank you for your great work on this project. As mentioned, I've been using it for many years and always thought it was awesome, so please see the above as constructive feedback rather than criticism. I really value all the hard work that has gone into FreeMarker. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
