Hi Timothy,
I have started to play with OSGI, in particular OSCAR. From the little I
could gather, while separation into API+Binding jars can be a requirement
under some circumstances, it is not a requirement for OSGI.
For example, the servlet API is delivered as a separate jar file because
otherwise web-servers would not be able to isolate web-applications.
Since I brought the issue up, I am not against the jar separation approach
but I am still unsure whether jar separation is required/advantageous in an
OSGI context.
Cheers,
At 09:46 PM 7/20/2006, Timothy Bennett wrote:
On 7/16/06, Ceki Gülcü <<mailto:[EMAIL PROTECTED]>[EMAIL PROTECTED]> wrote:
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)
I'm a big fan of separation of API and implementation artifacts. When you
write components that plugin to a runtime (such as what you have with
IoC), separation like this makes it nicer for the component to compile
against an API and the runtime to provide the implementation(s).
For instance, with OSGi, the implementation(s) of the Logging Service
could provide the slf4j implementation(s), while individual bundles only
have to be concerned with a dep on the slf4j-api.
Steven McConnell sold me on this approach a long time ago, and I still
think it's a good idea.
--
timothy
--
Ceki Gülcü
http://ceki.blogspot.com/
