I agree with everything Gary says on this one. Furthermore, I still believe some of these should move to their own repo.
Ralph > On Sep 9, 2023, at 6:51 AM, Gary Gregory <garydgreg...@gmail.com> wrote: > > Hi All. > >> * raise the Java requirements in 3.x to Java 17. > +1 fine w/ me. FWIW, my day job is migrating from Java 11 to 17 ATM. > >> * deprecate some modules in 2.x and drop them in 3.0.x, restore them if a >> user requests it in 3.1.x. > This feels arbitrary. First, we say 100k downloads, but then we say: > - "a big company with an internal Maven repo counts 1" > Count my day job in this category and our _large_ repo with _many_ > products and _many_ maintained versions. > - except "+ some modules under the line that are deemed important" by > what criteria? What's the point of setting an arbitrary "bar" if we > are going to make _further_ arbitrary exceptions? > It's just simpler to have no bar since all decisions will be > arbitrary; for example not having mongodb4 will be a problem for me > looking ahead and probably for the user who just reported an issue in > that code. > Each module should be evaluated and kept if anyone says "-1, please keep it". > > Gary > >> On Sat, Sep 9, 2023 at 3:15 AM Piotr P. Karwasz <piotr.karw...@gmail.com> >> wrote: >> >> Hi all, >> >> In a Slack discussion Volkan proposed (among other things) to: >> >> * raise the Java requirements in 3.x to Java 17. It is the same >> requirement as Spring Boot 3.x has, so I don't see a reason to lower >> the bar. Besides Java 21 will be an LTS. >> * deprecate some modules in 2.x and drop them in 3.0.x, restore them >> if a user requests it in 3.1.x. >> >> While the number of downloads is not the only criterium (a big company >> with an internal Maven repo counts 1, a student's project that tries >> multiple version counts more), these are the stats for last month: >> >> 1 log4j-bom 35178445 >> 2 log4j-api 30598923 >> 3 log4j-core 15567816 >> 4 log4j-to-slf4j 14036879 >> 5 log4j-slf4j-impl 8675173 >> 6 log4j-1.2-api 3454601 >> 7 log4j-jul 2120049 >> 8 log4j-web 1964937 >> 9 log4j-layout-template-json 1760437 >> 10 log4j-slf4j2-impl 1013605 >> 11 log4j-jcl 566636 >> 12 log4j-appserver 245029 >> 13 log4j-iostreams 209990 >> 14 log4j-spring-boot 87578 >> 15 log4j-spring-cloud-config-client 38332 >> 16 log4j-jakarta-web 37351 >> 17 log4j-jpl 20295 >> 18 log4j-flume-ng 14055 >> 19 log4j-taglib 13989 >> 20 log4j-couchdb 12781 >> 21 log4j-mongodb4 4623 >> 22 log4j-kubernetes 2618 >> 23 log4j-jpa 1252 >> 24 log4j-mongodb3 1143 >> 25 log4j-docker 1122 >> 26 log4j-cassandra 898 >> 27 log4j-jakarta-smtp 741 >> 28 log4j-jdbc-dbcp2 708 >> 29 log4j-to-jul 297 >> >> I propose to have a bar at 100k, so we keep everything up to >> `log4j-iostreams` + some modules under the line that are deemed >> important. >> >> I would keep `log4j-to-jul`, mainly because it is a third >> implementation of the Log4j API and I used it at work, when I didn't >> get the permission to use Log4j Core. NB: the `2.x` version of >> `log4j-to-jul` will still work with the `3.x` version of `log4j-api`, >> but it might require a modularized version to be fully compatible. >> >> The stats of `log4j-appserver` are unexpected. I guess the Jetty 9.x >> support drives it (Jetty 9.x reached EOL) more than the Tomcat >> support. So we could even deprecate this one and create a >> `log4j-tomcat` module or drop it entirely (I will pick up the Tomcat >> part in my `eu.copernik` modules). >> >> Piotr >> >> PS: The downloads of the 3.x modules split from `log4j-core` are not >> that great either. In the third column I renormalize them so that >> `log4j-core` has 15M downloads: >> log4j-core 78627 15567816 >> 1 log4j-jdbc 55 10890 >> 2 log4j-layout-jackson 55 10890 >> 3 log4j-jndi 44 8712 >> 4 log4j-script 44 8712 >> 5 log4j-kafka 40 7920 >> 6 log4j-jms 39 7722 >> 7 log4j-csv 38 7524 >> 8 log4j-jeromq 37 7326 >> 9 log4j-smtp 37 7326 >> 10 log4j-layout-jackson-json 33 6534 >> 11 log4j-layout-jackson-xml 30 5940 >> 12 log4j-layout-jackson-yaml 24 4752
