[slf4j-user] Fail Silently on NOP implementation

Steven Schlansker sschlansker at opentable.com
Thu Apr 28 23:11:23 UTC 2016


> On Apr 28, 2016, at 3:58 PM, Robert Elliot <rob at lidalia.org.uk> wrote:
> 
> 
>> 
>> As I have said, this distinction is artificial.
> 
> Unless your dependency mechanism allows for defining different dependencies for an artefact when it is running as a process or acting as a library for a different process (and Maven’s transitive dependency system, which has become the de facto standard, does not) there is no perfect solution for this. In the case of SLF4J there are the following options:
> 
> 1) Add a dependency on slf4j-nop to the artefact. This will badly affect anyone who depends on your artefact as a library to their process; they will find themselves with multiple SLF4J implementations on the classpath, which will at a minimum print an error and 50% of the time will ‘win’ and remove all their logging output and require them to work out how to exclude slf4j-nop to get it back. As Maven in XML has no (non-hacky) means of global dependency exclusion this may be a significant headache for them.

Could you simply declare an "optional" dependency on your implementation of choice?

This will be present when the JAR is invoked as an application, but will not
participate in the transitive dependencies inherited when used as a library?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mailman.qos.ch/pipermail/slf4j-user/attachments/20160428/d6f19bdd/attachment.sig>


More information about the slf4j-user mailing list