Hi,
From our private conversation:
Ceki: Hello Heiko, Thank you for starting the slf4s effort. I am interested in providing logging for the Scala language. Would you be interested to have slf4s ship as part of the slf4j project? Heiko: Definitely yes! Scala support in SLF4J is ways better than "my private" project. Let's make that happen! Ceki: Great. Could we please continue this discussion on the slf4j-dev mailing list? Just post a message saying that you are interested in contributing slf4s to the slf4j project. Here we go ;-) 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 Stambecco, highly scalable computing: stambecco.org Akka - Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Actors: akkasource.org
Hello Heiko, If you do not mind, I'd like to get the administrate hurdles cleared first. Could you please read the QOS.ch contributor license agreement? It can be found at: http://logback.qos.ch/cla.txt If you agree with its terms please sign and return by postal mail as indicated in the document. I think log4s should be part of the slf4j build. If you concur, then please fork the slf4j project [1] in order to add a new module hosting the contents of the slf4s project. If you are unfamiliar with Maven, I can help you set up. Once that is done, send me a pull request. Let me know what you think or if you run into trouble, -- Ceki [1] http://github.com/ceki/slf4j On 06/09/2010 8:32 AM, Heiko Seeberger wrote:
Hi,
From our private conversation:
Ceki: Hello Heiko, Thank you for starting the slf4s effort. I am interested in providing logging for the Scala language. Would you be interested to have slf4s ship as part of the slf4j project?
Heiko: Definitely yes! Scala support in SLF4J is ways better than "my private" project. Let's make that happen!
Ceki: Great. Could we please continue this discussion on the slf4j-dev mailing list? Just post a message saying that you are interested in contributing slf4s to the slf4j project.
Here we go ;-)
Heiko
Hi Ceki, On 6 September 2010 20:23, Ceki Gülcü <ceki@qos.ch> wrote:
If you do not mind, I'd like to get the administrate hurdles cleared first. Could you please read the QOS.ch contributor license agreement? It can be found at:
If you agree with its terms please sign and return by postal mail as indicated in the document.
Agreed and on its way.
I think log4s should be part of the slf4j build. If you concur, then please fork the slf4j project [1] in order to add a new module hosting the contents of the slf4s project. If you are unfamiliar with Maven, I can help you set up. Once that is done, send me a pull request.
I am quite familiar with Maven, used it a lot for Scala and OSGi before I became an SBT [1] fanboy. Getting slf4s in won't be a big deal. Most important question: How should we name the artifact? slf4j-scala-api? slf4j-scala? slf4s-api? slf4s? And how should we name the package? As SLF4S also has got a Logger trait (interface) we need a package different from org.slf4j. I think that org.slf4s is the best choice for the package and therefore the artifact should be slf4s-api. What do you think? One more thing: I did a lot of OSGi work and I prefer to have the manifest files generated by the great BND tool [2]. There is also the Felix Bundle Plugin which brings BND to Maven. I would like to continue to use it and later convince you to also use it for the rest of SLF4J, because the manifests will just be better (e.g. version policies lead to high quality version ranges, uses directive will be calculated, etc.). Any objections against the first step (using it for SLF4S)? By the way: I really like the fact that SLF4J is OSGi compliant! Good job! Heiko [1] http://code.google.com/p/simple-build-tool [2] http://www.aqute.biz/Code/Bnd 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 06/09/2010 9:41 PM, Heiko Seeberger wrote:
Hi Ceki,
On 6 September 2010 20:23, Ceki Gülcü <ceki@qos.ch <mailto:ceki@qos.ch>> wrote:
If you do not mind, I'd like to get the administrate hurdles cleared first. Could you please read the QOS.ch contributor license agreement? It can be found at:
If you agree with its terms please sign and return by postal mail as indicated in the document.
Agreed and on its way.
Great. As you know, SLF4J is distributed under the MIT license which is widely recognized as a universal donor license. It makes sense to apply the same license to all code shipping with SLF4J.
I think log4s should be part of the slf4j build. If you concur, then please fork the slf4j project [1] in order to add a new module hosting the contents of the slf4s project. If you are unfamiliar with Maven, I can help you set up. Once that is done, send me a pull request.
I am quite familiar with Maven, used it a lot for Scala and OSGi before I became an SBT [1] fanboy. Getting slf4s in won't be a big deal. Most important question: How should we name the artifact? slf4j-scala-api? slf4j-scala? slf4s-api? slf4s? And how should we name the package? As SLF4S also has got a Logger trait (interface) we need a package different from org.slf4j. I think that org.slf4s is the best choice for the package and therefore the artifact should be slf4s-api. What do you think?
The naming question is actually harder than it seems. The choice of the package name could drive the name of the module. How about org.slf4j.scala for the package name and slf4j-scala for the module name? The org.slf4s package name is nice except that it has no corresponding web-site (which of course can be remedied). More importantly, the org.sfl4s package name does not convey the relationship between slf4j and slf4s. If slf4s code ships with slf4j, then I think it should be under the org.slf4j namespace. Given this namespace constraint, org.slf4j.scala is the best I could come up with.
One more thing: I did a lot of OSGi work and I prefer to have the manifest files generated by the great BND tool [2]. There is also the Felix Bundle Plugin which brings BND to Maven. I would like to continue to use it and later convince you to also use it for the rest of SLF4J, because the manifests will just be better (e.g. version policies lead to high quality version ranges, uses directive will be calculated, etc.). Any objections against the first step (using it for SLF4S)? By the way:
As long as the other slf4j modules are not impacted I have no objections. As you intimated, the slf4j-scala/slf4s module could serve as a showcase for BND for the rest of slf4j.
I really like the fact that SLF4J is OSGi compliant! Good job!
Thank you.
Heiko
-- Ceki
On 6 September 2010 22:52, Ceki Gülcü <ceki@qos.ch> wrote: The naming question is actually harder than it seems.
Like always ;-) In this particular case we have to be very careful, because SLF4J is an extremely popular and widely spread piece of software and we are talking about API naming.
The choice of the package name could drive the name of the module. How about org.slf4j.scala for the package name and slf4j-scala for the module name?
As SLF4S is not a (bridge to a) logging backend, I think it should have "api" in its name just like slf4j-api => slf4j-scala-api or slf4j-api-scala.
The org.slf4s package name is nice except that it has no corresponding web-site (which of course can be remedied). More importantly, the org.sfl4s package name does not convey the relationship between slf4j and slf4s. If slf4s code ships with slf4j, then I think it should be under the org.slf4j namespace. Given this namespace constraint, org.slf4j.scala is the best I could come up with.
I agree with you that we have to use org.slf4j as the name of the root package. If we are going for subpackages, then org.slf4j.scala would probably be the best choice. In Scala versions prior to 2.8 you better didn't use "scala" as a package name, but SLF4S is for 2.8 and higher where this isn't an issue any more. But nevertheless I don't like using "scala" as a package name. First it simply feels wrong, but that's probably just me. Second and more important, there is no semantic value in "scala". Therefore we could also choose a different approach: Just use org.slf4j as the package name and call the types differently. Actually it's only Logger which is used in both SLF4J and SLF4S. Why not call it SLogger (for ScalaLogger or SmartLogger or ...). How do you like that idea? Regarding OSGi support we of course would have to make the slf4j-api-scala module a fragment of slf4j-api in order to avoid the split package issue. 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
participants (2)
-
Ceki Gülcü -
Heiko Seeberger