On 15/09/2010 11:30 PM, Hugues Malphettes wrote:
As a general answer: let's try with BND and review carefully the
generated manifests.
On Wed, Sep 15, 2010 at 1:40 PM, Ceki Gülcü<[email protected]> wrote:
On 15/09/2010 9:03 AM, Heiko Seeberger wrote:
Hi,
My recent changes to the POM of the slf4j-scala-api module show how we
should IMHO be doing OSGi in every module: Don't write the whole
manifest manually, but let the Maven Bundle plugin generate it.
Looking at the manifest of slf4j-api there are several issues:
* There is no Bundle-Version
The pom.xml does actually insert a Bundle-Version
I downloaded
http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.6.1/slf4j-api-1.6.1.jar
and verified that it is there.
The pom.xml is customized to insert the Bundle-Version without using
BND. Certainly a bit unusual but it does the job.
* The bundle symbolic name does not follow "well recognized OSGi
conventions": It should follow the reverse domain naming
convention, i.e. org.slf4j.api
Wouldn't this cause other bundles expecting the current symbolic name to
fail?
Yes it would make them fail.
The best practice for consumer bundles is to use the Import-Package
directive so that they don't depend on the naming of the bundle
itself.
So it all depends how many of the consumers of slf4j-api are following
the best practice or using Require-Bundle.
If that makes a difference: the re-packaging of slf4j on eclipse-orbit
is following the best practice mentioned by Heiko:
http://download.eclipse.org/tools/orbit/downloads/drops/S20100831105311/
If it was just me: I would say +1 for following the reverse domain naming.
Ok, then. Let's do it.
* I guess that SLF4J is compiled to target 1.5. At least for the JUL
module it has to be 1.4 at minimum. Therefore I doubt that the 1.3
execution environment ist the correct setting
SLF4J targets JDK 1.4.
Yes we should update that entry of the manifest.
Ack (short for acknowledge).
* I think the import for org.slf4j.impl should be optional, but I
have to play with that one
Hugues spent some time to tweak the manifests. I'd seek his input.
We spent quite some time looking into getting rid of the cyclic
dependency between slf4j-api and its implementation.
http://bugzilla.slf4j.org/show_bug.cgi?id=75
Gunnar went with the fragment approach on eclipse orbit:
http://bugzilla.slf4j.org/show_bug.cgi?id=75#c16 It is my favorite
approach so far.
I had done a funny experiment to wire the implementation to the API
dynamically. Frankly I would not use that: it is too much complexity
for no good reason. We could also use a Dynamic-Import.
If one of us has the need and the time we could develop something OSGi
specific to be able to plug and unplug slf4j implementations
dynamically.
I guess such functionality targets applications which can never ever be
stopped. Changing logging frameworks is something one does very few
times (if ever) during the lifetime of an application and on those
occasions you stop, update and restart the running instances.
If I remember well the import is not marked as optional because the
bundle does not work unless there is in fact a bundle that provides
the org.slf4j.impl package. I don't have a strong argument to decide
whether it should be optional or not.
* There is no uses directive for the exported packages. Well, that
cannot be done manually (see Maven Bundle plugin above)
Let's look at what is generated by BND.
OK, let's give BND a shot.
I'm on IRC freenode #slf4j if this type of communication helps.
Thanks for the offer. I don't think I'll hang around that irc channel
(or any other irc channel), but appreciate the offer nonetheless.
--
Ceki
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
