OSGi support in slf4j
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 bundle symbolic name does not follow "well recognized OSGi conventions": It should follow the reverse domain naming convention, i.e. org.slf4j.api - 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 - I think the import for org.slf4j.impl should be optional, but I have to play with that one - There is no uses directive for the exported packages. Well, that cannot be done manually (see Maven Bundle plugin above) I suggest I give it a try and change the slf4j-api module to also use the Maven Bundle plugin. Thoughts? Heiko Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
Hi Heiko, Thanks for all the good work on scala and looking in depth into slf4j in OSGi.
There is no uses directive for the exported packages. Well, that cannot be done manually (see Maven Bundle plugin above) I am not convinced that the use directive is necessary for slf4j. I have not seen a situation for slf4j where the use directive will solve an actual problem. I am afraid that the use directive automatically generated by BND will reflect in the bundle the version of the various jars used during the build: not new constraints that we did not identify and expressed in the manifest already.
In my experience, I had to relax the use directive in some manifests generated by BND. The use directive would specify that it only works with a different version of a library. In fact it just meant that it was built with a newer version of a library than the one imposed to my environment. The most common case is for packages provided by the JDK such as javax.xml. A BND generated manifest compiled with a specific stax version on the class path will specify in its use directive that it requires javax.xml with a version number. Another library would be compiled with jdk6 instead. BND will then specify that this particular package uses the version "0" of javax.xml. At runtime OSGi will refuse to load in the same class-space those 2 libraries because both of them rely on different and incompatible versions of javax.xml Relaxing the manifest of those bundles by removing the use-directive has been the best solution I found so far. Thanks for your attention, Hugues On Wed, Sep 15, 2010 at 12:03 AM, Heiko Seeberger <heiko.seeberger@googlemail.com> 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 bundle symbolic name does not follow "well recognized OSGi conventions": It should follow the reverse domain naming convention, i.e. org.slf4j.api 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 I think the import for org.slf4j.impl should be optional, but I have to play with that one There is no uses directive for the exported packages. Well, that cannot be done manually (see Maven Bundle plugin above)
I suggest I give it a try and change the slf4j-api module to also use the Maven Bundle plugin. Thoughts? Heiko
Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
Hi Hugues, Thanks a lot for your attention! Not sure, but as far as I understand, you probably got something wrong regarding the uses directive: There is no version! The only piece of information that is given is that an exported package "uses" some other packages, e.g. org.slf4j.scala uses types from scala.*. Only the packages, no versions. But that's enough to enable the OSGi container to make a consistent classpath. I know that this is an advanced topic, but it is a really important one. There are good examples in the OSGi spec. Regarding Scala's binary compatibility issues the uses directive is very important. And it is helpful in a lot of cases. There are almost no cases where it causes trouble. Therefore I suggest to use it. Heiko On Wednesday, September 15, 2010, Hugues Malphettes <hmalphettes@intalio.com> wrote:
Hi Heiko,
Thanks for all the good work on scala and looking in depth into slf4j in OSGi.
There is no uses directive for the exported packages. Well, that cannot be done manually (see Maven Bundle plugin above) I am not convinced that the use directive is necessary for slf4j. I have not seen a situation for slf4j where the use directive will solve an actual problem. I am afraid that the use directive automatically generated by BND will reflect in the bundle the version of the various jars used during the build: not new constraints that we did not identify and expressed in the manifest already.
In my experience, I had to relax the use directive in some manifests generated by BND. The use directive would specify that it only works with a different version of a library. In fact it just meant that it was built with a newer version of a library than the one imposed to my environment.
The most common case is for packages provided by the JDK such as javax.xml. A BND generated manifest compiled with a specific stax version on the class path will specify in its use directive that it requires javax.xml with a version number. Another library would be compiled with jdk6 instead. BND will then specify that this particular package uses the version "0" of javax.xml. At runtime OSGi will refuse to load in the same class-space those 2 libraries because both of them rely on different and incompatible versions of javax.xml Relaxing the manifest of those bundles by removing the use-directive has been the best solution I found so far.
Thanks for your attention, Hugues
On Wed, Sep 15, 2010 at 12:03 AM, Heiko Seeberger <heiko.seeberger@googlemail.com> 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 bundle symbolic name does not follow "well recognized OSGi conventions": It should follow the reverse domain naming convention, i.e. org.slf4j.api 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 I think the import for org.slf4j.impl should be optional, but I have to play with that one There is no uses directive for the exported packages. Well, that cannot be done manually (see Maven Bundle plugin above)
I suggest I give it a try and change the slf4j-api module to also use the Maven Bundle plugin. Thoughts? Heiko
Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
Heiko, It would be reassuring to the OSGi layman like myself, if both you and Hugues could reach consensus on this topic. It was a rather lengthy process to reach the current level of stability wrt OSGi manifests in SLF4J. On 15/09/2010 9:18 PM, Heiko Seeberger wrote:
Hi Hugues,
Thanks a lot for your attention!
Not sure, but as far as I understand, you probably got something wrong regarding the uses directive: There is no version! The only piece of information that is given is that an exported package "uses" some other packages, e.g. org.slf4j.scala uses types from scala.*. Only the packages, no versions. But that's enough to enable the OSGi container to make a consistent classpath. I know that this is an advanced topic, but it is a really important one. There are good examples in the OSGi spec.
Regarding Scala's binary compatibility issues the uses directive is very important. And it is helpful in a lot of cases. There are almost no cases where it causes trouble. Therefore I suggest to use it.
Heiko
On Wednesday, September 15, 2010, Hugues Malphettes <hmalphettes@intalio.com> wrote:
Hi Heiko,
Thanks for all the good work on scala and looking in depth into slf4j in OSGi.
There is no uses directive for the exported packages. Well, that cannot be done manually (see Maven Bundle plugin above) I am not convinced that the use directive is necessary for slf4j. I have not seen a situation for slf4j where the use directive will solve an actual problem. I am afraid that the use directive automatically generated by BND will reflect in the bundle the version of the various jars used during the build: not new constraints that we did not identify and expressed in the manifest already.
In my experience, I had to relax the use directive in some manifests generated by BND. The use directive would specify that it only works with a different version of a library. In fact it just meant that it was built with a newer version of a library than the one imposed to my environment.
The most common case is for packages provided by the JDK such as javax.xml. A BND generated manifest compiled with a specific stax version on the class path will specify in its use directive that it requires javax.xml with a version number. Another library would be compiled with jdk6 instead. BND will then specify that this particular package uses the version "0" of javax.xml. At runtime OSGi will refuse to load in the same class-space those 2 libraries because both of them rely on different and incompatible versions of javax.xml Relaxing the manifest of those bundles by removing the use-directive has been the best solution I found so far.
Thanks for your attention, Hugues
On Wed, Sep 15, 2010 at 12:03 AM, Heiko Seeberger <heiko.seeberger@googlemail.com> 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 bundle symbolic name does not follow "well recognized OSGi conventions": It should follow the reverse domain naming convention, i.e. org.slf4j.api 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 I think the import for org.slf4j.impl should be optional, but I have to play with that one There is no uses directive for the exported packages. Well, that cannot be done manually (see Maven Bundle plugin above)
I suggest I give it a try and change the slf4j-api module to also use the Maven Bundle plugin. Thoughts? Heiko
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 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?
* 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.
* 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.
* There is no uses directive for the exported packages. Well, that cannot be done manually (see Maven Bundle plugin above)
ditto -- Ceki
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ü <ceki@qos.ch> 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.
* 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.
* 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. 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. I'm on IRC freenode #slf4j if this type of communication helps. Best regards, Hugues.
ditto
-- Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
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ü<ceki@qos.ch> 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
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. Sorry for the confusion. I meant #qos.ch as mentioned on http://logback.qos.ch/mailinglist.html Cheers, Hugues
On Wed, Sep 15, 2010 at 10:07 PM, Ceki Gülcü <ceki@qos.ch> wrote:
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ü<ceki@qos.ch> 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 slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
On 15 September 2010 23:30, Hugues Malphettes <hmalphettes@intalio.com>wrote: As a general answer: let's try with BND and review carefully the
generated manifests.
Ack! 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.
My fault, sorry for the spam! I can see it now, no clue where it was hiding yesterday ;-)
If it was just me: I would say +1 for following the reverse domain naming.
Let's bump up the version and announce that change. Then users should know. I hope that almost nobody would use the bundle symbolic name anyway. 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.
It's OK for a bundle to be in a stale state (not working) because of missing dependencies, services, etc. Maybe this case is different, though. I will take a closer look. Heiko Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
Am 16.09.2010 07:57, schrieb Heiko Seeberger:
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.
It's OK for a bundle to be in a stale state (not working) because of missing dependencies, services, etc. Maybe this case is different, though. I will take a closer look.
If you go with the fragment approach, no import of "org.slf4j.impl" is necessary. In order to ensure that at least (as well as at most) one implementation is available, we use the GenericRequire bundle header as well as custom p2 instructions for installing one. http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.orbit/org.slf4j.api/?ro... -Gunnar -- Gunnar Wagenknecht gunnar@wagenknecht.org http://wagenknecht.org/
Gunnar, Thanks for your input! You know, you are doing evil proprietary things ;-) Heiko On 16 September 2010 08:58, Gunnar Wagenknecht <gunnar@wagenknecht.org>wrote:
Am 16.09.2010 07:57, schrieb Heiko Seeberger:
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.
It's OK for a bundle to be in a stale state (not working) because of missing dependencies, services, etc. Maybe this case is different, though. I will take a closer look.
If you go with the fragment approach, no import of "org.slf4j.impl" is necessary. In order to ensure that at least (as well as at most) one implementation is available, we use the GenericRequire bundle header as well as custom p2 instructions for installing one.
http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.orbit/org.slf4j.api/?ro...
-Gunnar
-- Gunnar Wagenknecht gunnar@wagenknecht.org http://wagenknecht.org/
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
Folks, My first shot at OSGi work for slf4j-api can be taken from here (not yet ready for pulling into the main repo): http://github.com/weiglewilczek/slf4j/tree/osgi Now the Felix Bundle plugin creates the manifest. It looks like below (not the plain manifest, but the output of analyzing with BND). As you can see all the issues I recently brought up are addressed, e.g. naming convention for Bundle-Symbolicname, execution environment bumped up to 1.4, etc. As all the logging backends are fragments I excluded org.slf4j.impl package from imported packages. This means you can install the slf4j-api bundle in an OSGi container successfully without a backend. Not sure whether this is what we want. Very important: The whole build still succeeds. What do you think? Can we proceed this way? Heiko slf4j$ bnd print slf4j-api/target/slf4j-api-1.6.2-SNAPSHOT.jar +++ Starting BND +++ [MANIFEST slf4j-api-1.6.2-SNAPSHOT.jar] Bnd-LastModified 1284623539661 Build-Jdk 1.6.0_20 Built-By hseeberger Bundle-Description The slf4j API Bundle-DocURL http://www.qos.ch Bundle-License http://www.opensource.org/licenses/mit-license.php Bundle-ManifestVersion 2 Bundle-Name SLF4J API Module Bundle-RequiredExecutionEnvironment J2SE-1.4 Bundle-SymbolicName org.slf4j.api Bundle-Vendor QOS.ch Bundle-Version 1.6.2.SNAPSHOT Created-By Apache Maven Bundle Plugin Export-Package org.slf4j.spi;uses:="org.slf4j";version="1.6.2.SNAPSHOT",org.slf4j.helpers;uses:="org.slf4j.spi,org.slf4j";version="1.6.2.SNAPSHOT",org.slf4j;uses:="org.slf4j.helpers,org.slf4j.spi";version="1.6.2.SNAPSHOT" Ignore-Package org.slf4j.impl Implementation-Title slf4j-api Import-Package org.slf4j;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.helpers;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.spi;version="[1.6.2.SNAPSHOT,1.7)" Manifest-Version 1.0 Tool Bnd-0.0.357 [IMPEXP] Export-Package org.slf4j {version=1.6.2.SNAPSHOT} org.slf4j.helpers {version=1.6.2.SNAPSHOT} org.slf4j.spi {version=1.6.2.SNAPSHOT} [USES] org.slf4j org.slf4j.helpers org.slf4j.impl org.slf4j.spi org.slf4j.helpers org.slf4j org.slf4j.spi org.slf4j.spi org.slf4j
Ceki, Hugues, Any comments on my work? Should I proceed that way for the other modules? Heiko On 16 September 2010 10:11, Heiko Seeberger <heiko.seeberger@googlemail.com>wrote:
Folks,
My first shot at OSGi work for slf4j-api can be taken from here (not yet ready for pulling into the main repo): http://github.com/weiglewilczek/slf4j/tree/osgi
Now the Felix Bundle plugin creates the manifest. It looks like below (not the plain manifest, but the output of analyzing with BND). As you can see all the issues I recently brought up are addressed, e.g. naming convention for Bundle-Symbolicname, execution environment bumped up to 1.4, etc.
As all the logging backends are fragments I excluded org.slf4j.impl package from imported packages. This means you can install the slf4j-api bundle in an OSGi container successfully without a backend. Not sure whether this is what we want.
Very important: The whole build still succeeds.
What do you think? Can we proceed this way?
Heiko
slf4j$ bnd print slf4j-api/target/slf4j-api-1.6.2-SNAPSHOT.jar +++ Starting BND +++ [MANIFEST slf4j-api-1.6.2-SNAPSHOT.jar] Bnd-LastModified 1284623539661
Build-Jdk 1.6.0_20
Built-By hseeberger
Bundle-Description The slf4j API
Bundle-DocURL http://www.qos.ch
Bundle-License http://www.opensource.org/licenses/mit-license.php Bundle-ManifestVersion 2
Bundle-Name SLF4J API Module
Bundle-RequiredExecutionEnvironment J2SE-1.4
Bundle-SymbolicName org.slf4j.api
Bundle-Vendor QOS.ch
Bundle-Version 1.6.2.SNAPSHOT
Created-By Apache Maven Bundle Plugin
Export-Package org.slf4j.spi;uses:="org.slf4j";version="1.6.2.SNAPSHOT",org.slf4j.helpers;uses:="org.slf4j.spi,org.slf4j";version="1.6.2.SNAPSHOT",org.slf4j;uses:="org.slf4j.helpers,org.slf4j.spi";version="1.6.2.SNAPSHOT" Ignore-Package org.slf4j.impl
Implementation-Title slf4j-api
Import-Package org.slf4j;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.helpers;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.spi;version="[1.6.2.SNAPSHOT,1.7)" Manifest-Version 1.0
Tool Bnd-0.0.357
[IMPEXP] Export-Package org.slf4j {version=1.6.2.SNAPSHOT} org.slf4j.helpers {version=1.6.2.SNAPSHOT} org.slf4j.spi {version=1.6.2.SNAPSHOT}
[USES] org.slf4j org.slf4j.helpers org.slf4j.impl org.slf4j.spi org.slf4j.helpers org.slf4j org.slf4j.spi org.slf4j.spi org.slf4j
-- Heiko Seeberger Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
Hello all, I pulled in changes made by Heiko http://github.com/ceki/slf4j/pull/2. Here is the version of the MANIFEST file from slf4j-api-1.6.1.jar. Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: ceki Build-Jdk: 1.6.0_16 Bundle-Description: The slf4j API Bundle-Version: 1.6.1 Implementation-Version: 1.6.1 Implementation-Title: slf4j-api Bundle-ManifestVersion: 2 Bundle-SymbolicName: slf4j.api Bundle-Name: slf4j-api Bundle-Vendor: SLF4J.ORG Bundle-RequiredExecutionEnvironment: J2SE-1.3 Export-Package: org.slf4j;version=1.6.1, org.slf4j.spi;version=1.6.1, org.slf4j.helpers;version=1.6.1 Import-Package: org.slf4j.impl;version=1.6.0 Here is the version generated after Heiko's changes have been applied: Manifest-Version: 1.0 Export-Package: org.slf4j.spi;uses:="org.slf4j";version="1.6.2.SNAPSHO T",org.slf4j.helpers;uses:="org.slf4j.spi,org.slf4j";version="1.6.2.S NAPSHOT",org.slf4j;uses:="org.slf4j.helpers,org.slf4j.spi";version="1 .6.2.SNAPSHOT" Ignore-Package: org.slf4j.impl Implementation-Title: slf4j-api Built-By: ceki Tool: Bnd-0.0.357 Bundle-Name: SLF4J API Module Created-By: Apache Maven Bundle Plugin Bundle-RequiredExecutionEnvironment: J2SE-1.4 Bundle-Vendor: QOS.ch Build-Jdk: 1.6.0_16 Bundle-Version: 1.6.2.SNAPSHOT Bnd-LastModified: 1288644768461 Bundle-ManifestVersion: 2 Bundle-License: http://www.opensource.org/licenses/mit-license.php Bundle-Description: The slf4j API Bundle-DocURL: http://www.qos.ch Bundle-SymbolicName: org.slf4j.api Import-Package: org.slf4j;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.hel pers;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.spi;version="[1.6.2.SNA PSHOT,1.7)" Admittedly, I am a little lost. The previous MANIFEST file imported org.slf4j.impl, whereas the latest MANIFEST does not. Strangely enough, org.slf4j.impl is not mentioned at all. In earlier message Heiko wrote:
As all the logging backends are fragments I excluded org.slf4j.impl package from imported packages. This means you can install the slf4j-api bundle in an OSGi container successfully without a backend. Not sure whether this is what we want.
I think it makes life easier if the slf4j-api bundle can be installed without a back-end. However, this is assuming that a desired back-end bundle can be installed and successfully bound with slf4j-api. (It is an obvious requirement but still may be useful to mention.) This version can be pulled in either from http://github.com/weiglewilczek/slf4j (master) or from http://github.com/ceki/slf4j (weiglewilczek-master). Your comments are most welcome, -- Ceki
Hi Ceki, Thanks for reminding us to review the changes introduced by BND. On Mon, Nov 1, 2010 at 2:16 PM, Ceki Gülcü <ceki@qos.ch> wrote:
Hello all,
I pulled in changes made by Heiko http://github.com/ceki/slf4j/pull/2. Here is the version of the MANIFEST file from slf4j-api-1.6.1.jar.
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: ceki Build-Jdk: 1.6.0_16
Bundle-Description: The slf4j API Bundle-Version: 1.6.1 Implementation-Version: 1.6.1 Implementation-Title: slf4j-api Bundle-ManifestVersion: 2 Bundle-SymbolicName: slf4j.api Bundle-Name: slf4j-api Bundle-Vendor: SLF4J.ORG Bundle-RequiredExecutionEnvironment: J2SE-1.3 Export-Package: org.slf4j;version=1.6.1, org.slf4j.spi;version=1.6.1, org.slf4j.helpers;version=1.6.1 Import-Package: org.slf4j.impl;version=1.6.0
Here is the version generated after Heiko's changes have been applied:
Manifest-Version: 1.0
Export-Package: org.slf4j.spi;uses:="org.slf4j";version="1.6.2.SNAPSHO T",org.slf4j.helpers;uses:="org.slf4j.spi,org.slf4j";version="1.6.2.S NAPSHOT",org.slf4j;uses:="org.slf4j.helpers,org.slf4j.spi";version="1 .6.2.SNAPSHOT" Ignore-Package: org.slf4j.impl Implementation-Title: slf4j-api Built-By: ceki
Tool: Bnd-0.0.357 Bundle-Name: SLF4J API Module Created-By: Apache Maven Bundle Plugin Bundle-RequiredExecutionEnvironment: J2SE-1.4 Bundle-Vendor: QOS.ch Build-Jdk: 1.6.0_16
Bundle-Version: 1.6.2.SNAPSHOT Bnd-LastModified: 1288644768461 Bundle-ManifestVersion: 2
Bundle-License: http://www.opensource.org/licenses/mit-license.php Bundle-Description: The slf4j API Bundle-DocURL: http://www.qos.ch Bundle-SymbolicName: org.slf4j.api
Import-Package: org.slf4j;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.hel pers;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.spi;version="[1.6.2.SNA PSHOT,1.7)"
Admittedly, I am a little lost. The previous MANIFEST file imported org.slf4j.impl, whereas the latest MANIFEST does not. Strangely enough, org.slf4j.impl is not mentioned at all.
Heiko packages org.slf4j.impl as bundle fragments that are hosted by org.slf4j.api. In our situation, there must not be more than one provider of org.slf4j.impl: this means there must one and exactly one fragment that provides org.slf4j.impl. At runtime the fragment classes are part of the classloader of org.slf4j.api. This is why org.slf4j.api does not import org.slf4j.impl at all. The MANIFEST.MF of org.slf4j.api does look good. It contains a few of extra lines that are read by BND alone: Private-Package and Bnd-LastModified for example. The MANIFEST.MF of jcl.over.slf4j (aka jcl-over-slf4j) uses these statements: Export-Package: org.apache.commons.logging;version=1.1.1, org.apache. commons.logging.impl;version=1.1.1 Import-Package: org.slf4j;version=1.6.2.SNAPSHOT, org.slf4j.spi;versio n=1.6.2.SNAPSHOT It will work. The versioning constrain on the import-package is I think too much: strictly speaking, the produced fragment is going to work with version 1.6 of slf4j. I apologize for sounding picky and in the case where we always build and distribute together slf4j-api and jcl-over-slf4j it probably does not matter much. If we were to adopt BND to generate the MANIFESTs of logback let's make sure that we generate version=1.6 only so that we don't suddenly force everyone to upgrade both slf4j and logback at once for no actual reason. Best regards, Hugues
In earlier message Heiko wrote:
As all the logging backends are fragments I excluded org.slf4j.impl package from imported packages. This means you can install the slf4j-api bundle in an OSGi container successfully without a backend. > Not sure whether this is what we want.
I think it makes life easier if the slf4j-api bundle can be installed without a back-end. However, this is assuming that a desired back-end bundle can be installed and successfully bound with slf4j-api. (It is an obvious requirement but still may be useful to mention.)
This version can be pulled in either from http://github.com/weiglewilczek/slf4j (master) or from http://github.com/ceki/slf4j (weiglewilczek-master).
Your comments are most welcome,
-- Ceki
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
Thank you for reviewing! If I understand correctly we should relax the versioning policy to import ranges from x.y instead of x.y.z, right? IMHO that makes sense. An it's easily done: Just a little switch in the config. Let me know and I will change it. Heiko On Tuesday, November 2, 2010, Hugues Malphettes <hmalphettes@intalio.com> wrote:
Hi Ceki,Thanks for reminding us to review the changes introduced by BND. On Mon, Nov 1, 2010 at 2:16 PM, Ceki Gülcü <ceki@qos.ch> wrote: Hello all,
I pulled in changes made by Heiko http://github.com/ceki/slf4j/pull/2. Here is the version of the MANIFEST file from slf4j-api-1.6.1.jar.
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: ceki Build-Jdk: 1.6.0_16 Bundle-Description: The slf4j API
Bundle-Version: 1.6.1 Implementation-Version: 1.6.1 Implementation-Title: slf4j-api Bundle-ManifestVersion: 2 Bundle-SymbolicName: slf4j.api Bundle-Name: slf4j-api Bundle-Vendor: SLF4J.ORG Bundle-RequiredExecutionEnvironment: J2SE-1.3 Export-Package: org.slf4j;version=1.6.1, org.slf4j.spi;version=1.6.1, org.slf4j.helpers;version=1.6.1 Import-Package: org.slf4j.impl;version=1.6.0
Here is the version generated after Heiko's changes have been applied:
Manifest-Version: 1.0 Export-Package: org.slf4j.spi;uses:="org.slf4j";version="1.6.2.SNAPSHO T",org.slf4j.helpers;uses:="org.slf4j.spi,org.slf4j";version="1.6.2.S NAPSHOT",org.slf4j;uses:="org.slf4j.helpers,org.slf4j.spi";version="1 .6.2.SNAPSHOT" Ignore-Package: org.slf4j.impl Implementation-Title: slf4j-api
Built-By: ceki Tool: Bnd-0.0.357
Bundle-Name: SLF4J API Module
Created-By: Apache Maven Bundle Plugin
Bundle-RequiredExecutionEnvironment: J2SE-1.4
Bundle-Vendor: QOS.ch Build-Jdk: 1.6.0_16 Bundle-Version: 1.6.2.SNAPSHOT
Bnd-LastModified: 1288644768461 Bundle-ManifestVersion: 2 Bundle-License: http://www.opensource.org/licenses/mit-license.php Bundle-Description: The slf4j API Bundle-DocURL: http://www.qos.ch
Bundle-SymbolicName: org.slf4j.api Import-Package: org.slf4j;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.hel pers;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.spi;version="[1.6.2.SNA PSHOT,1.7)"
Admittedly, I am a little lost. The previous MANIFEST file imported org.slf4j.impl, whereas the latest MANIFEST does not. Strangely enough, org.slf4j.impl is not mentioned at all. Heiko packages org.slf4j.impl as bundle fragments that are hosted by org.slf4j.api.
In our situation, there must not be more than one provider of org.slf4j.impl: this means there must one and exactly one fragment that provides org.slf4j.impl.
At runtime the fragment classes are part of the classloader of org.slf4j.api.This is why org.slf4j.api does not import org.slf4j.impl at all. The MANIFEST.MF of org.slf4j.api does look good.
It contains a few of extra lines that are read by BND alone: Private-Package and Bnd-LastModified for example.
The MANIFEST.MF of jcl.over.slf4j (aka jcl-over-slf4j) uses these statements: Export-Package: org.apache.commons.logging;version=1.1.1, org.apache. commons.logging.impl;version=1.1.1
Import-Package: org.slf4j;version=1.6.2.SNAPSHOT, org.slf4j.spi;versio n=1.6.2.SNAPSHOT It will work.The versioning constrain on the import-package is I think too much: strictly speaking, the produced fragment is going to work with version 1.6 of slf4j.
I apologize for sounding picky and in the case where we always build and distribute together slf4j-api and jcl-over-slf4j it probably does not matter much.If we were to adopt BND to generate the MANIFESTs of logback let's make sure that we generate version=1.6 only so that we don't suddenly force everyone to upgrade both slf4j and logback at once for no actual reason.
Best regards,Hugues
In earlier message Heiko wrote:
As all the logging backends are fragments I excluded org.slf4j.impl package from imported packages. This means you can install the slf4j-api bundle in an OSGi container successfully without a backend. > Not sure whether this is what we want.
I think it makes life easier if the slf4j-api bundle can be installed without a back-end. However, this is assuming that a desired back-end bundle can be installed and successfully bound with slf4j-api. (It is an obvious requirement but still may be useful to mention.)
This version can be pulled in either from http://github.com/weiglewilczek/slf4j (master) or from http://github.com/ceki/slf4j (weiglewilczek-master).
Your comments are most welcome,
--
Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
On Tue, Nov 2, 2010 at 2:43 PM, Heiko Seeberger < heiko.seeberger@googlemail.com> wrote:
Thank you for reviewing!
If I understand correctly we should relax the versioning policy to import ranges from x.y instead of x.y.z, right? IMHO that makes sense. An it's easily done: Just a little switch in the config. Let me know and I will change it.
That would be the one thing I would change. Thanks Heiko! Hugues
Heiko
On Tuesday, November 2, 2010, Hugues Malphettes <hmalphettes@intalio.com> wrote:
Hi Ceki,Thanks for reminding us to review the changes introduced by BND. On Mon, Nov 1, 2010 at 2:16 PM, Ceki Gülcü <ceki@qos.ch> wrote: Hello all,
I pulled in changes made by Heiko http://github.com/ceki/slf4j/pull/2. Here is the version of the MANIFEST file from slf4j-api-1.6.1.jar.
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: ceki Build-Jdk: 1.6.0_16 Bundle-Description: The slf4j API
Bundle-Version: 1.6.1 Implementation-Version: 1.6.1 Implementation-Title: slf4j-api Bundle-ManifestVersion: 2 Bundle-SymbolicName: slf4j.api Bundle-Name: slf4j-api Bundle-Vendor: SLF4J.ORG Bundle-RequiredExecutionEnvironment: J2SE-1.3 Export-Package: org.slf4j;version=1.6.1, org.slf4j.spi;version=1.6.1, org.slf4j.helpers;version=1.6.1 Import-Package: org.slf4j.impl;version=1.6.0
Here is the version generated after Heiko's changes have been applied:
Manifest-Version: 1.0 Export-Package: org.slf4j.spi;uses:="org.slf4j";version="1.6.2.SNAPSHO T",org.slf4j.helpers;uses:="org.slf4j.spi,org.slf4j";version="1.6.2.S NAPSHOT",org.slf4j;uses:="org.slf4j.helpers,org.slf4j.spi";version="1 .6.2.SNAPSHOT" Ignore-Package: org.slf4j.impl Implementation-Title: slf4j-api
Built-By: ceki Tool: Bnd-0.0.357
Bundle-Name: SLF4J API Module
Created-By: Apache Maven Bundle Plugin
Bundle-RequiredExecutionEnvironment: J2SE-1.4
Bundle-Vendor: QOS.ch Build-Jdk: 1.6.0_16 Bundle-Version: 1.6.2.SNAPSHOT
Bnd-LastModified: 1288644768461 Bundle-ManifestVersion: 2 Bundle-License: http://www.opensource.org/licenses/mit-license.php Bundle-Description: The slf4j API Bundle-DocURL: http://www.qos.ch
Bundle-SymbolicName: org.slf4j.api Import-Package: org.slf4j;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.hel pers;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.spi;version="[1.6.2.SNA PSHOT,1.7)"
Admittedly, I am a little lost. The previous MANIFEST file imported org.slf4j.impl, whereas the latest MANIFEST does not. Strangely enough, org.slf4j.impl is not mentioned at all. Heiko packages org.slf4j.impl as bundle fragments that are hosted by org.slf4j.api.
In our situation, there must not be more than one provider of org.slf4j.impl: this means there must one and exactly one fragment that provides org.slf4j.impl.
At runtime the fragment classes are part of the classloader of org.slf4j.api.This is why org.slf4j.api does not import org.slf4j.impl at all. The MANIFEST.MF of org.slf4j.api does look good.
It contains a few of extra lines that are read by BND alone: Private-Package and Bnd-LastModified for example.
The MANIFEST.MF of jcl.over.slf4j (aka jcl-over-slf4j) uses these statements: Export-Package: org.apache.commons.logging;version=1.1.1, org.apache. commons.logging.impl;version=1.1.1
Import-Package: org.slf4j;version=1.6.2.SNAPSHOT, org.slf4j.spi;versio n=1.6.2.SNAPSHOT It will work.The versioning constrain on the import-package is I think too much: strictly speaking, the produced fragment is going to work with version 1.6 of slf4j.
I apologize for sounding picky and in the case where we always build and distribute together slf4j-api and jcl-over-slf4j it probably does not matter much.If we were to adopt BND to generate the MANIFESTs of logback let's make sure that we generate version=1.6 only so that we don't suddenly force everyone to upgrade both slf4j and logback at once for no actual reason.
Best regards,Hugues
In earlier message Heiko wrote:
As all the logging backends are fragments I excluded org.slf4j.impl package from imported packages. This means you can install the slf4j-api bundle in an OSGi container successfully without a backend. > Not sure whether this is what we want.
I think it makes life easier if the slf4j-api bundle can be installed without a back-end. However, this is assuming that a desired back-end bundle can be installed and successfully bound with slf4j-api. (It is an obvious requirement but still may be useful to mention.)
This version can be pulled in either from http://github.com/weiglewilczek/slf4j (master) or from http://github.com/ceki/slf4j (weiglewilczek-master).
Your comments are most welcome,
--
Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger
Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
Did it and sent pull request to Ceki. Heiko On 2 November 2010 23:27, Hugues Malphettes <hmalphettes@intalio.com> wrote:
On Tue, Nov 2, 2010 at 2:43 PM, Heiko Seeberger < heiko.seeberger@googlemail.com> wrote:
Thank you for reviewing!
If I understand correctly we should relax the versioning policy to import ranges from x.y instead of x.y.z, right? IMHO that makes sense. An it's easily done: Just a little switch in the config. Let me know and I will change it.
That would be the one thing I would change. Thanks Heiko! Hugues
Heiko
On Tuesday, November 2, 2010, Hugues Malphettes <hmalphettes@intalio.com> wrote:
Hi Ceki,Thanks for reminding us to review the changes introduced by BND. On Mon, Nov 1, 2010 at 2:16 PM, Ceki Gülcü <ceki@qos.ch> wrote: Hello all,
I pulled in changes made by Heiko http://github.com/ceki/slf4j/pull/2. Here is the version of the MANIFEST file from slf4j-api-1.6.1.jar.
Manifest-Version: 1.0 Archiver-Version: Plexus Archiver Created-By: Apache Maven Built-By: ceki Build-Jdk: 1.6.0_16 Bundle-Description: The slf4j API
Bundle-Version: 1.6.1 Implementation-Version: 1.6.1 Implementation-Title: slf4j-api Bundle-ManifestVersion: 2 Bundle-SymbolicName: slf4j.api Bundle-Name: slf4j-api Bundle-Vendor: SLF4J.ORG Bundle-RequiredExecutionEnvironment: J2SE-1.3 Export-Package: org.slf4j;version=1.6.1, org.slf4j.spi;version=1.6.1, org.slf4j.helpers;version=1.6.1 Import-Package: org.slf4j.impl;version=1.6.0
Here is the version generated after Heiko's changes have been applied:
Manifest-Version: 1.0 Export-Package: org.slf4j.spi;uses:="org.slf4j";version="1.6.2.SNAPSHO T",org.slf4j.helpers;uses:="org.slf4j.spi,org.slf4j";version="1.6.2.S NAPSHOT",org.slf4j;uses:="org.slf4j.helpers,org.slf4j.spi";version="1 .6.2.SNAPSHOT" Ignore-Package: org.slf4j.impl Implementation-Title: slf4j-api
Built-By: ceki Tool: Bnd-0.0.357
Bundle-Name: SLF4J API Module
Created-By: Apache Maven Bundle Plugin
Bundle-RequiredExecutionEnvironment: J2SE-1.4
Bundle-Vendor: QOS.ch Build-Jdk: 1.6.0_16 Bundle-Version: 1.6.2.SNAPSHOT
Bnd-LastModified: 1288644768461 Bundle-ManifestVersion: 2 Bundle-License: http://www.opensource.org/licenses/mit-license.php Bundle-Description: The slf4j API Bundle-DocURL: http://www.qos.ch
Bundle-SymbolicName: org.slf4j.api Import-Package: org.slf4j;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.hel pers;version="[1.6.2.SNAPSHOT,1.7)",org.slf4j.spi;version="[1.6.2.SNA PSHOT,1.7)"
Admittedly, I am a little lost. The previous MANIFEST file imported org.slf4j.impl, whereas the latest MANIFEST does not. Strangely enough, org.slf4j.impl is not mentioned at all. Heiko packages org.slf4j.impl as bundle fragments that are hosted by org.slf4j.api.
In our situation, there must not be more than one provider of org.slf4j.impl: this means there must one and exactly one fragment that provides org.slf4j.impl.
At runtime the fragment classes are part of the classloader of org.slf4j.api.This is why org.slf4j.api does not import org.slf4j.impl at all. The MANIFEST.MF of org.slf4j.api does look good.
It contains a few of extra lines that are read by BND alone: Private-Package and Bnd-LastModified for example.
The MANIFEST.MF of jcl.over.slf4j (aka jcl-over-slf4j) uses these statements: Export-Package: org.apache.commons.logging;version=1.1.1, org.apache. commons.logging.impl;version=1.1.1
Import-Package: org.slf4j;version=1.6.2.SNAPSHOT, org.slf4j.spi;versio n=1.6.2.SNAPSHOT It will work.The versioning constrain on the import-package is I think too much: strictly speaking, the produced fragment is going to work with version 1.6 of slf4j.
I apologize for sounding picky and in the case where we always build and distribute together slf4j-api and jcl-over-slf4j it probably does not matter much.If we were to adopt BND to generate the MANIFESTs of logback let's make sure that we generate version=1.6 only so that we don't suddenly force everyone to upgrade both slf4j and logback at once for no actual reason.
Best regards,Hugues
In earlier message Heiko wrote:
As all the logging backends are fragments I excluded org.slf4j.impl package from imported packages. This means you can install the slf4j-api bundle in an OSGi container successfully without a backend. > Not sure whether this is what we want.
I think it makes life easier if the slf4j-api bundle can be installed without a back-end. However, this is assuming that a desired back-end bundle can be installed and successfully bound with slf4j-api. (It is an obvious requirement but still may be useful to mention.)
This version can be pulled in either from http://github.com/weiglewilczek/slf4j (master) or from http://github.com/ceki/slf4j (weiglewilczek-master).
Your comments are most welcome,
--
Ceki _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger
Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org _______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
-- Heiko Seeberger Company: weiglewilczek.com Blog: heikoseeberger.name Follow me: twitter.com/hseeberger OSGi on Scala: scalamodules.org Lift, the simply functional web framework: liftweb.net Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
Am 16.09.2010 09:01, schrieb Heiko Seeberger:
You know, you are doing evil proprietary things ;-)
Hehe, #therewillbeanrfcforthis ;) -Gunnar -- Gunnar Wagenknecht gunnar@wagenknecht.org http://wagenknecht.org/
On 16.09.2010 07:57, Heiko Seeberger wrote:
On 15 September 2010 23:30, Hugues Malphettes <hmalphettes@intalio.com <mailto:hmalphettes@intalio.com>> wrote:
As a general answer: let's try with BND and review carefully the generated manifests.
Ack!
Sorry for not replying earlier. I was away for the last two weeks. It seemed to me that we had already reached consensus on using BND. So please go ahead with the planned changes. -- Ceki
participants (5)
-
Ceki Gulcu -
Ceki Gülcü
-
Gunnar Wagenknecht -
Heiko Seeberger -
Hugues Malphettes