|
Home > Archive > Apache Directory Project > July 2006 > Separating API and binding
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Separating API and binding
|
|
| Ceki Gülcü 2006-07-16, 1:11 pm |
|
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?
Your comments are most welcome.
--=20
Ceki G=FClc=FC
http://ceki.blogspot.com/
| |
| John E. Conlon 2006-07-17, 1:11 pm |
| 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?
>
> Your comments are most welcome.
>
>
>
| |
| Alex Karasulu 2006-07-17, 7:11 pm |
| John E. Conlon wrote:[vbcol=seagreen]
> 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:
How about having 2 deps now instead of 1? How are other users reacting
to this?
Alex
| |
| Ceki Gülcü 2006-07-17, 7:11 pm |
|
At 09:25 PM 7/17/2006, Alex Karasulu wrote:
>How about having 2 deps now instead of 1? How are other users reacting to=
=20
>this?
It's too early to tell. However, I tend to think that with the help of=20
dependency management tool like Maven or classpath definition using *.jar=20
pattern with Ant, increasing the number of dependencies becomes less of an=
=20
issue.
>Alex
--=20
Ceki G=FClc=FC
http://ceki.blogspot.com/
| |
| Alex Karasulu 2006-07-17, 7:11 pm |
| Ceki Gülcü wrote:
>
>
> At 09:25 PM 7/17/2006, Alex Karasulu wrote:
>
>
> It's too early to tell. However, I tend to think that with the help of
> dependency management tool like Maven or classpath definition using
> *.jar pattern with Ant, increasing the number of dependencies becomes
> less of an issue.
>
Fair nuf! You I good.
Alex
| |
| Timothy Bennett 2006-07-20, 7:11 pm |
| On 7/16/06, Ceki Gülcü <listid@qos.ch> 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ü 2006-07-20, 7:11 pm |
|
Hi Timothy,
I have started to play with OSGI, in particular OSCAR. From the little I=20
could gather, while separation into API+Binding jars can be a requirement=20
under some circumstances, it is not a requirement for OSGI.
For example, the servlet API is delivered as a separate jar file because=20
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=
=20
but I am still unsure whether jar separation is required/advantageous in an=
=20
OSGI context.
Cheers,
At 09:46 PM 7/20/2006, Timothy Bennett wrote:
>On 7/16/06, Ceki G=C3=BClc=C3=BC <<mailto:listid-vdLmLxQ6Fys@public.gmane.org>listid-vdLmLxQ6Fys@public.gmane.org>=
wrote:
>
>I'm a big fan of separation of API and implementation artifacts. When you=
=20
>write components that plugin to a runtime (such as what you have with=20
>IoC), separation like this makes it nicer for the component to compile=20
>against an API and the runtime to provide the implementation(s).
>
>For instance, with OSGi, the implementation(s) of the Logging Service=20
>could provide the slf4j implementation(s), while individual bundles only=20
>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=20
>think it's a good idea.
>
>--
>timothy
--=20
Ceki G=FClc=FC
http://ceki.blogspot.com/
| |
| Timothy Bennett 2006-07-27, 1:11 pm |
| On 7/20/06, Ceki Gülcü <listid@qos.ch> wrote:
>
>
> 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.
You are correct, of course. Not a requirement at all. In fact, bundle
developers who are attempting to keep their service "simple" prefer (I
think) to package the API along with it's implementation. OSGi, while
initially target for device and mobile deployments, is quickly finding
itself appropriate for many other solution domains -- including the
enterprise. In situations where you may have a number of possible
implementations (as their own bundle) of a common API, it might would be an
advantage to have a separate API.
I think it is context driven with neither way being the right/best way. Not
sure that helps with any packaging decisions! 
--
timothy
|
|
|
|
|