On 06/09/2010 9:41 PM, Heiko Seeberger wrote:
Hi Ceki,

On 6 September 2010 20:23, Ceki Gülcü <[email protected] <mailto:[email protected]>>
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:

    http://logback.qos.ch/cla.txt

    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
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev

Reply via email to