Multiple slf4j bindings

[mramsden]

trafficstars

I'm looking to use this library in an existing web project which is also using log4j. I saw that there was some previous discussion about this on #34.

After adding 1.18 to my project there is an error with multiple slf4j bindings existing both in the logback library we are already using and in the opentimestamp jar which is causing a resolution issue at runtime. I saw that there was an associated PR to fix this situation by excluding the slf4j simple jar but from what I can tell the bundled jar from mavenCentral still includes the dependency.

Is there a way that this could be worked around by splitting the project into two jars. One providing the CLI functionality and the other providing the api functionality?

[RCasatta]

In your project, did you include the OpenTimestamp dep as suggested in https://github.com/opentimestamps/java-opentimestamps/issues/34#issuecomment-521068886 ?

[mramsden]

Yep. I should have mentioned in my original message that I'm using Gradle rather than Maven. I did try adding the exclusion for the group in the dependency like this:

implementation("com.eternitywall:java-opentimestamps:1.18") {
    exclude(group = "org.slf4j", module = "slf4j-simple")
}

Unfortunately that didn't work. I did some further exploration and found that the JAR up on Maven Central currently includes the slf4j-simple and it's associated class files. I have made a temporary workaround by building my own version of the library and replacing slf4j-simple with slf4j-api which I was able to get things working with, but this means that I need to pay close attention to the other dependencies that the java-opentimestamps library requires.

[RCasatta]

Yeah, sorry, we should separate the cli (with slf4j-simple) from the API (with slf4j-api) as previously discussed

[mramsden]

Are you open to pull requests for making updates to this kind of thing?

[RCasatta]

yes, but at the moment it is not a priority for me, you should expect long review times

[RCasatta]

e8b5e58 is the only thing required?

[mramsden]

Apologies I missed your notification amongst all my other ones. I think there is still a small bit more to do around testing the CLI support with the logging. I'm using that fork for now to get things building for our specific use case where we use the JAR directly as a library.

There are two avenues that I'm investigating:

First is there a way that the project could be built that allows the production of a lib only JAR for use with other applications whilst still allowing the production of an executable JAR that includes the slf4j-simple dependency so that the CLI still logs as expected. A lot of the suggestions that I can find online is that it is a preferred approach to create a multi-module project with multiple POM files. One would declare the dependencies for opentimestamps-core, this artefact would contain the core apis and timestamp creation functionality. Another would declare the dependencies for creating OtsCli.jar but this would end up being quite a few changes to land.

Second it appears slf4j is not used throughout the library, instead java.util.logging is used. The outcome of this is the configuration in our application environment which means that we do get some extra logging in our application when we are doing OpenTimestamp operations. Would you be open to replacing the usage of java.util.logging with slf4j?

I would be interested in any thoughts or questions that you have around these.

[lvaccaro]

First case would be a nice improvement, but also the core library could need something log, maybe you are considering to use only java.util.logging in core library, right?

At the moment, slf4j looks never used, so it could be remove from pom.xml.