tools-build 2023-06-01

hi everybody, I see that tools.build has org.slf4j/slf4j-nop as a dependency, which silence all logging on applications that use tools.build as a transitive dependency. What is the reason for it? I imagine most people only use tools.build from build scripts where that is not a problem, but is kind of inconvenient when using it as a dependency for other libs

Alex Miller (Clojure team) 2023-06-01T18:30:11.387069Z

You can easily add it back

yeah, I ended up excluding it from my lib, since a user was complaining "when using your lib I suddenly don't have logs"

but is it a good default?

Alex Miller (Clojure team) 2023-06-01T18:32:26.862139Z

For most people, yes

Alex Miller (Clojure team) 2023-06-01T18:32:54.571299Z

Can you explain how it was affecting someone else? I don’t get it

so, FlowStorm debugger uses tools.build as a dep, it uses it for generating jars. A user was asking why when adding FlowStorm to the classpath their app stopped logging

Alex Miller (Clojure team) 2023-06-01T18:44:11.029419Z

That still doesn’t make sense

Alex Miller (Clojure team) 2023-06-01T18:44:33.905239Z

Oh wait, I’m sorry, it does

Alex Miller (Clojure team) 2023-06-01T18:44:47.183999Z

I was thinking it was an exclusion not an added dep

yeah, so now I have an exclusion, so my lib jar doesn't drag slf4j-nop and don't surprise its users

Alex Miller (Clojure team) 2023-06-01T18:45:45.391669Z

Most users of tools.build are end users, not libs

yeah that I was imaging

but I think tools.build has a nice set of tools to be used from other libs, not only from build scripts

I'm surprised more people are not using https://github.com/BrunoBonacci/mulog for logging. I've used it on the last few commercial projects and its so much simpler and more effective to work with logs as data and integration with logging services is straight-forward. I even have mulog event logs pushed to Portal data inspector, as the logs are maps 🙂

well, even if you are using mulog it can silence your java logging