> > As I have said, this distinction is artificial. It isn’t, in my opinion. The distinction between a process and a library is fundamental. A process must, of its nature, have resolved all its dependencies to concrete implementations. A library should, of its nature, couple as lightly as possible to implementations of APIs it depends on in order to free the hands of the process depending on that library.
It is of course easy to create an artefact that can be both be run as a process and depended on as a library, but that conflates two separate concerns and doing so is inherently problematic. 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. 2) Silently do a nop in SLF4J if no implementation is present. This will give no hint to the unaware user as to why they are getting no logging feedback from their process and what they should do to fix it. 3) Exit the process aggressively (via an exception) if no logging implementation is present 4) Separate the artefact into two artefacts - one a library containing 99% of the logic and depending on slf4j-api alone, and the other a main method that depends on the library and slf4j-nop, and document which the user should use depending on whether they want a library or a process. 5) Print some description as to how to provide an SLF4J implementation and otherwise allow the process to carry on There are other approaches, and possibly better ones, to logging than SLF4J - I’m far from convinced that the static procedural approach where the implementation is looked up and used without the caller having control is a good one. But we are where we are, and libraries routinely statically depend on slf4j, so 5) seems to me the least bad . Rob _______________________________________________ slf4j-user mailing list slf4j-user@qos.ch http://mailman.qos.ch/mailman/listinfo/slf4j-user
