At 08:34 PM 11/23/2005, John Franey wrote:
I don't think it is a stupid question.
Flexibility. A plug-in developed using SLF4J as an external plug-in can
swap between SLF4J variants (jdk, log4j, nlog4j, custom). A plug-in which
embeds an SLF4J library will be bound to use the corresponding
framework. I think an RCP developer would prefer the former plug-in,
only because the RCP developer can chose which framework the application
would use.
Memory/disk footprint: If every plug-in embedded a logger library....
Runtime confusion in Eclipse: If every plug-in with a logging library
exported it, Eclipse would non-deterministically select one, any one, to
satisfy another plug-ins import.
Those are main reasons.
Makes sense. Thanks for the explanation.
Although you do not have to, you could license the code to slf4j.org so
that it could distribute your code. Alternatively, you could chose to
distribute your code on your own.
I will think this over. I currently leaning towards licensing the code
for slf4j to distribute. What does it mean to license the code, according
to slf4j? (My stupid question for the day).
Very succinctly, the idea is similar if not identical to what the ASF does.
The ASF requires contributors to license their contribution to the ASF in
such a way that the ASF can legally redistribute it. For more details, see
http://apache.org/licenses/icla.txt in particular sections 2, 4 and 5.
(Replace "foundation" by "slf4j.org").
This is a very rough sketch, please do not hesitate to ask questions if
anything is unclear. Once you agree to the contributors license, we could
proceed to create an account for you.
--
Ceki Gülcü
The complete log4j manual: http://www.qos.ch/log4j/
_______________________________________________
dev mailing list
[email protected]
http://slf4j.org/mailman/listinfo/dev
