Sorry, I was wrong about freemarker-7. I thought I Double checked... The build system really doesn't matter for the next major version. Sorry if I made that impression.
I'll try to recreate some other ideas for the 2.x branch. On Fri, 3 Nov 2023, 22:12 Benjamin Marwell, <bmarw...@apache.org> wrote: > Hi Daniel, > > > FREEMARKER-7 was closed in 2017, with the comment about why (Gradle) > > no, you closed it just as of today. IT was open and unlinked until > Hervé linked it.: > https://issues.apache.org/jira/browse/FREEMARKER-7 -- click the "all" > tab. > > > 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. > > Because I proposed an "intermediate" release with breaking changes. > According to semver, that's a new major version. > > Anyway, maybe I can get the stuff done in ant, who knows. > > As for the Maven relocation -- you can just ask on the Maven user mailing > list. > Even if you use ant or gradle, package relocation can be explained if > there are any open questions. > > > with the comment about why (Gradle) > > Well I did not see it in the issue as stated earlier, but please paste the > link > to the vote on the mailing into this issue, so we can see that it was > agreed on. > > Thanks! > > - Ben > > Am Do., 2. Nov. 2023 um 19:39 Uhr schrieb Daniel Dekany > <daniel.dek...@gmail.com>: > > > > 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 >
