We can add Jakarta support without any of these (as I noted in that closed PR), I think. We will certainly see in December. If you can solve something in isolation, that's generally a good thing.
Java modules compatibility. Is it not working currently? So every classes are are inside the package "freemarker" (I know, I know... very very old style). And also we have "Automatic-Module-Name: freemarker" in META-NIF. Is that something that is *technically* broken? Or is it just ugly? FREEMARKER-7 was closed in 2017, with the comment about why (Gradle). You say you stumbled into FREEMARKER-7 recently, and started working on your PR, which you sent last week. As of changing group name... only if ordinary users are not affected by it negatively. I did check the Maven relocation guide that you linked, but... I don't get it. Let's say, the user has two transitive dependencies in its application: freemarker:freemarker:2.3.32, and org.apache.freemarker:freemaker:2.3.99 (the version number doesn't matter now, but note that the group name was modernized between the two version). The switching, where you have published the both a relocation POM with the old group, and also the modernized POM in the new group, happened between the two, let's say, at 2.3.80. So in that situation, how will Maven (or Gradle, or SBT, etc.) know that these two groups are actually clashing, and they should only keep org.apache.freemarker:freemaker:2.3.99. See, this example project has never ever fetched a relocation POM. What am I missing? (Like, replacing all old POM-s with a relocation POM doesn't seem practical, as Maven repos meant to be append only basically. Like can I replace old POM in maven central? Will corporate Maven repo mirrors discover that?) Dropping support for old stuff... yeah, I want to create a 2.4.0 someday, that's a bit(!) more daring in that regard, like we don't support outregeously old stuff. But, again, if it only creates problems for users, and it's not a significant deal to drag the old dependencies, then it's not urgent. Like dropping support for non-Jakara is maybe something I would do in a 2.4. But... priorities. Like, java.time support, Java Record support, etc. These are what actually matter for users, and addressing these are also stretching forever. (Sorry, sorry... December spring is our next hope.) So I would rather invest energy into these kind of things. Also, the version number... Seems to me that you recommend releasing something called 3.0.0, which is 2.3.x with the changes you mention. So it's major version step up, with no new features users really care about, but doing some changes that breaks stuff for some of them. I mean... Why would we do such a thing, I don't get it. On Wed, Nov 1, 2023 at 9:06 PM Benjamin Marwell <bmarw...@apache.org> wrote: > Hello dev mailing list! > > Sorry I haven't subscribed earlier. Actually I had, but somehow > unsubscribed again. > However, I am a user of freemarker for various projects. One of the > projects is the Apache Shiro site (via jbake), then my personal blog > and a not-so-tiny project at work. > > However, I recently wanted to contribute back. > As a Maven PMC member, I spotted FREEMARKER-7 right away (migrate to > maven) and opened PR 96: https://github.com/apache/freemarker/pull/96 > However, I learned that there's a "more recent" branch which already > got converted to Gradle or at least will be. Then I saw another issue > (https://issues.apache.org/jira/browse/FREEMARKER-204) which > unfortunately has not been linked to FREEMARKER-7 and the vote on the > mailing lists which way to go has not been documented in either of > those issues. > > Anyway, with that gone, I wonder where I could actually contribute. > My (personal) dearest which would have been to move the 3-branch to 4 > to make room for another "intermedia" 3.0.0 release which only differs > from the current 2.x branch by: > > * Adding an additional jar with jakarta-classifier (maven-terminology) > * Maybe move to Java 11 > * proper module-info (could also be done on Java 8 if set up properly) > * Maybe drop old servlet 2.0 support, along with old JSP to have less > duplicated code > * Maven, if it helped (but that would probably not be worth it with > the project already going to Gradle). > * Relocation preparation (from freemarker to org.freemarker or > org.apache.freemarker) > * Adjusting the module name accordingly. > > The idea is to ease migration a bit by adding a simpler intermedia release. > > I would like to hear from the community what you all would think of this > idea. > > * No package relocation required > * No work for consumers (ie users) > * No work for migrating the current 3-branch except renaming the branch > > Best regards, > - Ben > -- Best regards, Daniel Dekany
