|Re: [cross-project-issues-dev] Can SLF4J be made the official logging API for Eclipse projects?|
If there is a conflict hazard then it already exists. Examining one of my workspaces...
Good (SLF4J) - jgit, m2e
Bad (LOG4J) - mwe, ocl, qvtd, xtend, xtext
This is complete news to me. I continue to use log4j since it avoids changing code styles that have been unchanged for many many years. Other projects probably just copy prevailing practice.
I presume changing is rather easy, and of no consequence to the exported API, since the use of log4j is by import package.
However without a commitment to change by Xtext, I would be reluctant to change any Xtext-based project.
Log4j 1.x reached end of life in 2015. The documentation for it now appears to have gone offline. There are some Eclipse projects (call them L1 projects) that currently use Log4j 1.x directly rather than SLF4J. That means that any projects that depend on L1 projects cannot use Log4J 2.x without risking dependency collisions from attempting to load multiple versions of Log4J.
SLF4J was created precisely to eliminate dependencies on specific logging implementations.
It is important that libraries like those that plug into Eclipse not unintentionally force a specific logging implementation on their users. Those library developers have no way of knowing – and probably no way of satisfying – all the requirements of their various sets of users.
Given that, it seems that Eclipse should make SLF4J the ‘official’ logging API for all Eclipse libraries.
Honeywell | Aerospace
_______________________________________________ cross-project-issues-dev mailing list cross-project-issues-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
Back to the top