Ceki,
Thanks for your response. My answers to your questions are inline.
John
Ceki Gülcü wrote:
Hello John,
You are obviously a few steps ahead of me. I'll try to answer when I
can, and ask questions otherwise.
More in line.
At 09:07 PM 11/22/2005, John Franey wrote:
Hi,
I've created a logging prototype in the Eclipse rich client platform
using slf4j and nlog4j. I've written an article about it which is in
its final draft. I'm about to submit it to the editors of
EclipseZone (http:www.eclipsezone.com), but there are some questions
I'd like to ask your development team.
I hope they accept your submission. However, regardless of their
decision, I suggest that you ask to keep the copyright so that you can
publish its contents elsewhere. In my experience, the publicity spurt
that an article in a magazine brings is not worth the steady diffusion
power of the article published on the web-pages of your project. Most
magazine editors (but not book editors) will let you keep the
copyright. In short, you license your article to the magazine but keep
the copyright.
Thanks for the advice. I forgot all about that take.
In the article, Eclipse plug-ins for the slf4j class libraries are
created and introduced; one plug-in for each slf4j variant. These
plug-ins are interchangeable and so allows seperation between the
application and logging framework. Also, because slf4j contains a
JCL implementation, the slf4j plug-ins can support other plug-ins
that use JCL. Way cool. Thanks for the library.
I am not familiar with Eclipse plug-ins (except as an Eclipse user).
What advantages does the plug-in form SLF4J have compared to the
stand-alone form? I apologize if this may seem like a stupid question.
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.
First question: The name of the plug-ins incorporate the name of your
organization: org.slf4j. Is this OK? Its a naming convention in
Eclipse plug-ins; to name a plug-in after the java package that it
implements. For example, a plug-in for LOG4J logging would be
called org.apache.log4j. Also, 99.9% of the code in the plug-in
originates from slf4j, not any other entity. The only code that I
provide are entries to a jar's MANIFEST.MF file.
The SLF4J is distributed under the X11 license (see
http://www.slf4j.org/license.html ) which is quite permissive. In
short, provided that:
the copyright notice(s) and this permission notice appear in all
copies of
the Software and that both the above copyright notice(s) and this
permission notice appear in supporting documentation.
You should be fine.
Second question: Its very easy for you to build and distribute your
library as Eclipse plug-ins, incorporating the modifications detailed
in the article. It requires only OSGi entries in the jar file's
MANIFEST.MF. Would you be interested in doing this?
Why not? However, as mentioned above, the advantages of distributing
SLF4J as Eclipse plug-ins are not entirely obvious to me :-).
Third question: I created a plug-in for an slf4j Logger
implementation over the Eclipse RCP logging framework. I used
org.slf4j in the name of the plug-in only to keep it consistent with
the other plug-in names in the article. Is that OK? Only the
Logger, LoggerFactory and binding classes are contributed by me, the
rest of the code is all yours and I'd like to maintain that credit
belongs to you.
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).
Fourth question: Could I contribute the slf4j on Eclipse logging to
your project? One objection you may have is that there are build
time dependencies on the Eclipse RCP libraries.
The Eclipse RCP library dependency is not a problem. In principle,
each binding already depends on some underlying library, e.g. log4j.
Dependencies on logging systems is what SLF4J is all about.
Let me contact you offline for details about creating an account for
you, commit rights etc on the slf4j.org server.
Thanks,
John
_______________________________________________
dev mailing list
[email protected]
http://slf4j.org/mailman/listinfo/dev
