January 2022 - slf4j-dev - mailman3.qos.ch

[JIRA] Updates for SLF4J-539: Gradle build fails with SLF4J 1.7.34
by QOS.CH (JIRA) 30 Jan '22

30 Jan '22

SLF4J / SLF4J-539 [Resolved] Gradle build fails with SLF4J 1.7.34 ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-539 ============================== 1 comment ------------------------------ Alexander Veit on 30/Jan/22 5:40 PM Vladimir, since the newer version 1.7.35 is in the Maven repository you have to replace '1.7.+' with '1.7.34' in the provided build.gradle to reproduce the error. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-540: Backward compatibility problem with 1.7.34 update
by QOS.CH (JIRA) 28 Jan '22

28 Jan '22

SLF4J / SLF4J-540 [Open] Backward compatibility problem with 1.7.34 update ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-540 ============================== 1 comment ------------------------------ Jeremy Landis on 28/Jan/22 3:16 AM @ceki Sorry it is a bit vague on purpose. All good, got some very useful information here I've passed on. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-540: Backward compatibility problem with 1.7.34 update
by QOS.CH (JIRA) 27 Jan '22

27 Jan '22

SLF4J / SLF4J-540 [Open] Backward compatibility problem with 1.7.34 update ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-540 ============================== 1 comment ------------------------------ Ceki Gülcü on 27/Jan/22 8:29 PM I seem to be missing a lot of context here. Anyway, glad that things seem to be sorted out? ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-540: Backward compatibility problem with 1.7.34 update
by QOS.CH (JIRA) 27 Jan '22

27 Jan '22

SLF4J / SLF4J-540 [Open] Backward compatibility problem with 1.7.34 update ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-540 ============================== 1 comment ------------------------------ Jeremy Landis on 27/Jan/22 8:14 PM @vladimirsitnikov thank you for that information. Corporate team not on my team but will report that to respective team as clearly needs fixed in our space. Appreciate you providing that. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-540: Backward compatibility problem with 1.7.34 update
by QOS.CH (JIRA) 27 Jan '22

27 Jan '22

SLF4J / SLF4J-540 [Open] Backward compatibility problem with 1.7.34 update ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-540 ============================== 1 comment ------------------------------ Vladimir Sitnikov on 27/Jan/22 7:35 PM @hazendaz, I maintain [https://github.com/vlsi/vlsi-release-plugins#license-gather-plugin] and I am surprised you went that far without the tool supporting the fetching the license from "parent pom". That was one of the first cases I had to support due to the very common use of the pattern. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-539: Gradle build fails with SLF4J 1.7.34
by QOS.CH (JIRA) 27 Jan '22

27 Jan '22

SLF4J / SLF4J-539 [Resolved] Gradle build fails with SLF4J 1.7.34 ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-539 ============================== 1 comment ------------------------------ Vladimir Sitnikov on 27/Jan/22 7:39 PM @Veit, please provide the reproducer. configurations.api.setCanBeResolved(true) should not be used. Prefer Sync task if you absolutely need to copy the jars (which you should rarely need in practice). Prefer runtimeClasspath or testRuntimeClasspath configurations or create your own configuration. api is non-resolvable, and there are good reasons for that. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-540: Backward compatibility problem with 1.7.34 update
by QOS.CH (JIRA) 27 Jan '22

27 Jan '22

SLF4J / SLF4J-540 [Open] Backward compatibility problem with 1.7.34 update ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-540 ============================== 1 comment ------------------------------ Jeremy Landis on 27/Jan/22 1:55 AM The tools used are not very 'maven' smart. It doesn't resolve the pom to determine what the license is, it physically looks at the pom and if its not listed, its blocked. Its not a big deal to me as we already have a CI rewrite to reload4j and notice for any log4j usage but for more widespread usage I'm sure others have this same problem. As a plus, mavens new central now shows this is relocated but still many are behind corporate domains that don't have direct access and far too many that don't even look in central. If anything, I'd just suggest adding the license again but otherwise needs no immediate attention. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-540: Backward compatibility problem with 1.7.34 update
by QOS.CH (JIRA) 26 Jan '22

26 Jan '22

SLF4J / SLF4J-540 [Open] Backward compatibility problem with 1.7.34 update ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-540 ============================== 1 comment ------------------------------ Ceki Gülcü on 26/Jan/22 10:31 AM The license information should be inherited from the parent pom. Or do you mean a copyright notice at the top of pom.xml file itself? The relocation feature is not well-documented but from the few simple tests I have performed, it works quite well. Also, users should eventually rename the {{slf4j-log4j}} dependency to {{slf4j-reload4j}}. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-540: Backward compatibility problem with 1.7.34 update
by QOS.CH (JIRA) 25 Jan '22

25 Jan '22

SLF4J / SLF4J-540 [Open] Backward compatibility problem with 1.7.34 update ============================== Here's what changed in this issue in the last few minutes. There are 2 comments. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-540 ============================== 2 comments ------------------------------ Jeremy Landis on 25/Jan/22 11:27 PM Try using [1.7.0,1.7.99) for your range instead of what you had. 1.8.0-beta4 is not standard with maven. So its not that surprising that a lessor used feature to relocate artifacts acts in odd ways. Another note on relocation poms, they are sort of useless in most use cases. For example, if you are behind firewalls and have to bring in jars, why would you want to bring in a pom to update? Its confusing at best and not well documented. That is why some relocation poms especially long time ago always had a JAR present so it was just the warning out to the build process. Further, tools like renovate / dependabot don't handle relocations. ------------------------------ Jeremy Landis on 25/Jan/22 11:32 PM One other thing, the relocation pom is missing a license. Even if everyone wanted to use, some cannot due to that fact. I do see some usefulness to the relocation as not everyone got the email notifications but it needs a bit more to be proper for those behind firewalls with systems like synk checking for proper licenses. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0

[JIRA] Updates for SLF4J-540: Backward compatibility problem with 1.7.34 update
by QOS.CH (JIRA) 25 Jan '22

25 Jan '22

SLF4J / SLF4J-540 [Open] Backward compatibility problem with 1.7.34 update ============================== Here's what changed in this issue in the last few minutes. There is 1 comment. View or comment on issue using this link https://jira.qos.ch/browse/SLF4J-540 ============================== 1 comment ------------------------------ Archie Cobbs on 25/Jan/22 6:44 PM Like I said, it works if I force the version to {{1.7.34}} (or {{1.7.35}} - just tried that as well). The problem seems to be that this "loose" version specification no longer works: {noformat} <slf4j.version>[1.7,1.8)</slf4j.version> {noformat} I don't know how or why Maven is able to choose {{org.slf4j:slf4j-api:jar:1.8.0-beta4:compile}} when the {{${slf4j.version\}}} has an _exclusive_ upper bound of {{1.8}}. So this seems like more of a Maven problem than an slf4j problem, but either way I don't completely understand it. ============================== This message was sent by Atlassian Jira (v8.8.0#808000-sha1:e2c7e59)

1 0