Deprecating modules in 2.x
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-core15567816 4 log4j-to-slf4j14036879 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-boot87578 15 log4j-spring-cloud-config-client 38332 16 log4j-jakarta-web37351 17 log4j-jpl20295 18 log4j-flume-ng 14055 19 log4j-taglib 13989 20 log4j-couchdb12781 21 log4j-mongodb44623 22 log4j-kubernetes 2618 23 log4j-jpa 1252 24 log4j-mongodb31143 25 log4j-docker 1122 26 log4j-cassandra898 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-jdbc55 10890 2 log4j-layout-jackson 55 10890 3 log4j-jndi44 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-smtp37 7326 10 log4j-layout-jackson-json 33 6534 11 log4j-layout-jackson-xml 30 5940 12 log4j-layout-jackson-yaml 24 4752
Re: Deprecating modules in 2.x
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 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-core15567816 > 4 log4j-to-slf4j14036879 > 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-boot87578 > 15 log4j-spring-cloud-config-client 38332 > 16 log4j-jakarta-web37351 > 17 log4j-jpl20295 > 18 log4j-flume-ng 14055 > 19 log4j-taglib 13989 > 20 log4j-couchdb12781 > 21 log4j-mongodb44623 > 22 log4j-kubernetes 2618 > 23 log4j-jpa 1252 > 24 log4j-mongodb31143 > 25 log4j-docker 1122 > 26 log4j-cassandra898 > 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-jdbc55 10890 > 2 log4j-layout-jackson 55 10890 > 3 log4j-jndi44 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-smtp37 7326 > 10 log4j-layout-jackson-json 33 6534 > 11 log4j-layout-jackson-xml 30 5940 > 12 log4j-layout-jackson-yaml 24 4752
Re: Deprecating modules in 2.x
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 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 >> 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-core15567816 >> 4 log4j-to-slf4j14036879 >> 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-boot87578 >> 15 log4j-spring-cloud-config-client 38332 >> 16 log4j-jakarta-web37351 >> 17 log4j-jpl20295 >> 18 log4j-flume-ng 14055 >> 19 log4j-taglib 13989 >> 20 log4j-couchdb12781 >> 21 log4j-mongodb44623 >> 22 log4j-kubernetes 2618 >> 23 log4j-jpa 1252 >> 24 log4j-mongodb31143 >> 25 log4j-docker 1122 >> 26 log4j-cassandra898 >> 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-jdbc55 10890 >> 2 log4j-layout-jackson 55 10890 >> 3 log4j-jndi44 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-smtp37 7326 >> 10 log4j-layout-jackson-json 33 6534 >> 11 log4j-layout-jackson-xml 30 5940 >> 12 log4j-layout-jackson-yaml 24 4752
Re: Deprecating modules in 2.x
Hi Gary, On Sat, 9 Sept 2023 at 15:51, Gary Gregory wrote: > > * 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. Nice to hear that. IIRC you were on Java 8 for a long time. > > * deprecate some modules in 2.x and drop them in 3.0.x, restore them if a > > user requests it in 3.1.x. > (...) > Each module should be evaluated and kept if anyone says "-1, please keep it". That's a better way to put it. All modules should be dropped except those that should not be dropped. ;-) My selection for those to drop would be: 12 log4j-appserver 245029 (possibly, not a priority) 14 log4j-spring-boot87578 (contained in Spring Boot 3.x) 15 log4j-spring-cloud-config-client 38332 (contained in Spring Boot 3.x?) 19 log4j-taglib 13989 20 log4j-couchdb12781 21 log4j-mongodb44623 22 log4j-kubernetes 2618 23 log4j-jpa 1252 24 log4j-mongodb31143 25 log4j-docker 1122 26 log4j-cassandra898 28 log4j-jdbc-dbcp2 708 Piotr
Re: Deprecating modules in 2.x
Please do not drop appserver, mongodb4, jdbc-dbcp2. Gary On Sat, Sep 9, 2023, 11:43 AM Piotr P. Karwasz wrote: > Hi Gary, > > On Sat, 9 Sept 2023 at 15:51, Gary Gregory wrote: > > > * 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. > > Nice to hear that. IIRC you were on Java 8 for a long time. > > > > * deprecate some modules in 2.x and drop them in 3.0.x, restore them > if a user requests it in 3.1.x. > > (...) > > Each module should be evaluated and kept if anyone says "-1, please keep > it". > > That's a better way to put it. All modules should be dropped except > those that should not be dropped. ;-) > > My selection for those to drop would be: > > 12 log4j-appserver 245029 (possibly, not a priority) > 14 log4j-spring-boot87578 (contained in Spring Boot > 3.x) > 15 log4j-spring-cloud-config-client 38332 (contained in Spring Boot > 3.x?) > 19 log4j-taglib 13989 > 20 log4j-couchdb12781 > 21 log4j-mongodb44623 > 22 log4j-kubernetes 2618 > 23 log4j-jpa 1252 > 24 log4j-mongodb31143 > 25 log4j-docker 1122 > 26 log4j-cassandra898 > 28 log4j-jdbc-dbcp2 708 > > Piotr >
Re: Deprecating modules in 2.x
Hi Gary, On Sat, 9 Sept 2023 at 18:07, Gary Gregory wrote: > > Please do not drop appserver, mongodb4, jdbc-dbcp2. What part of `appserver` are you using: Tomcat or Jetty 9.x? Should we keep Jetty 9.x support in 3.x (Jetty 10.x uses SLF4J and is not Jakartified). I like the way this is going, so let's agree on a list of modules that could be dropped, vote on it and announce it on `log4j-user` to get user's opinion. The current list of nominees: 1 log4j-spring-boot (contained in Spring Boot 3.x) 2 log4j-spring-cloud-config-client (contained in Spring Boot 3.x?) 3 log4j-taglib 4 log4j-couchdb 5 log4j-kubernetes 6 log4j-jpa 7 log4j-mongodb3 8 log4j-docker 9 log4j-cassandra >From 3.x might I nominate: 1 log4j-layout-jackson 2 log4j-csv 3 log4j-jeromq 4 log4j-layout-jackson-json 5 log4j-layout-jackson-xml 6 log4j-layout-jackson-yaml Piotr
