bmarwell commented on PR #96: URL: https://github.com/apache/freemarker/pull/96#issuecomment-1782721604
> As of migrating away from Ant, there's already a PR for a Gradle-based solution, that keeps binary backward compatibility, while still modularizes the source code (as it's in the current 3.x). That also can handle the cases where we depend on multiple versions of the same artifact (like even of Java), which we sometimes need (in 2.x, as we have a monolithic artifact, for backward compatibility). I know. But since we are Apache, you'd get plenty of help from other foundation members, committers etc. We already have an Apache-based project setup which adds the benefit of streamlined releases, reproducible releases etc. If you want to do the same work again, I won't stop you. But that means I cannot contribute, as my knowledge of Gradle is very limited. And that might be true for a lot of other Apache committers. As for the backward compatibility: Breaking changes is what major releases are for. It it was not breaking anything, don't update the major version. > As of the Maven package name change, I'm against changes that are annoyances for the users without bringing significant new benefits in exchange. No need to do that right now, BUT it would be worth it to streamline Apache projects. Again, if you need help -- the maven team can help you. > At least last time I checked, renaming a Maven group is a pain for its consumers, because then Maven won't do version conflict resolution between the old and new artifacts, and you end up having multiple versions of the same classes in your application. That is not entirely true. First of all, dependabot, renovate etc. can read the relocation from the pom.xml: https://maven.apache.org/guides/mini/guide-relocation.html > (So then you should also rename the Java packages, so the two artifacts can co-exist, but that's an even more drastic change, and should have really good reasons. Like when you want to break backward compatibility in template language rules anyway, as in the current 3.x, then you should do that. But not just for aesthetic reasons for sure.) Other projects did this as well, see Junit 4 to JUnit Jupiter. I never saw anyone being trapped with this. On the contrary, it was helpful that two major versions could co-exist: Migration does not need to be done at the same time for all files. This could be true for Freemarker. --- To summarize: With only the changes mentioned in the first post of the PR, users would have a migration release which does not expect a lot of work: * stay at single-jar dependency * relocation is pretty easy * renaming packages is pretty easy * module identifier is consistent, not split packages * Path to Java 8 opened * Abandon old JavaEE 5 APIs. Again, I am only saying "move your 3 branch to 4 and keep Gradle". I did not say "abandon it". The idea is that I want to use freemarker with JPMS *right now* and don't want to wait for the current-3-branch for two more years with so many breaking changes etc. which is way more pain. -- 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]
