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
