I am a library maintainer and I came to a point where I discovered that one of my libraries can result into a dependency issue for the end user as it provides a transitive dependency to the end users. The end-user might be using a different version of the transitive one and therefore it can result into unexpected behaviour. I don't want to enforce the end user to use a specific version by providing the transitive one however I still want my library to be functional and therefore I don't know what is the best way to solve this issue. Should I use the default dependency scope or should I switch to the scope provided?
I also want to provide some context to make this question more clear. I created sslcontext-kickstart which is just a high-level library for configuring ssl for a server or client. The library has additional separate dependencies which the end-user can use to make it more easy to use for their use case. So the core library has only a dependency on slf4j-api. However there are separate libraries which contain mappers which I also created for apache4, apache5, netty and jetty which relay on the core library. Apache4, apache5, netty and jetty are currently a compile scoped dependency and therefor the end-user will also get the version which is specified in my pom. Let's assume someone is using the apache4 version. So should the end-user exclude the dependency manually when they are using my library and don't want the specific transitive apache4 dependency? Or should I mark apache4 as provided scope type. In that way there will be no transitive dependency, however the end-user should have the apache4 dependency present on their classpath or else they will get a runtime exception when they use my library.
What do you guys think regarding this topic? What are my options and which should I choose in your opinion?
