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