John E. Conlon wrote:
Separating the API out into its own jar is a great idea.
Annotated the new jar manifests for OSGi package import/exporting would
be very beneficial as well.
thanks,
John
On Sun, 2006-07-16 at 15:41 +0200, Ceki Gülcü wrote:
Hello all,
It has been observes that while SLF4J offers abstraction of for
various logging systems through compile-time bindings, it bundles the
SLF4J API and a particular binding in a single jar file. Thus, we
currently have:
slf4j-nop.jar
slf4j-simple.jar
slf4j-jdk14.jar
slf4j-jul.jar
each of which contains a copy of SLF4J API and a corresponding binding.
I think it would be somewhat cleaner to separate the API in its own
jar file. Thus, we would have
slf4j-api.jar (just the API with no particular binding)
slf4j-nop.jar (only the nop binding, no API)
slf4j-simple.jar (only the simple binding, no API)
slf4j-jdk14.jar (only the jdk14 binding, no API)
slf4j-jul.jar (only the jul binding, no API)
The only down side to this approach is that the user would need to
deploy two jar files instead of one. The upside is a clearer
separation between API and implementation.
Is there any opposition to this approach?
How about having 2 deps now instead of 1? How are other users reacting
to this?
Alex