I agree that with hindsight the inclusion of DBAppender in Logback might
have been a mistake. If it were today, it probably would have not made
the cut.
My offer to reference ReporterAppender from logback's web-site still
stands.
On 1/12/2017 7:08, Scott Babcock wrote:
The set of appenders provided by the main Logback project includes
implementations for nine vendor-specific database products. The target
audience for each of these database appenders is significantly smaller
than the target audience for the TestNG Reporter appender provided by
this PR.
In a recent survey of dependency references in GitHub, the TestNG
library comes in at #20 on the list of the top 100 most frequently used
libraries. The only database flavor that comes close to this level of
popularity is MySQL, which came in at #26. HSQL comes in at #54, and the
remaining SQL flavors didn't make it onto the Top 100 list.
I can migrate the TestNG Reporter appender to a companion project
without the need to duplicate core unit test classes, by adding a
"test-jar" dependency to my Maven project. While this is functional,
it's less than ideal, as it makes this appender more difficult for
potential users to find.
Does any of these factors tip the balance in favor of incorporating this
new appender into the main Logback project?
------------------------------------------------------------------------
*From:* logback-dev <logback-dev-boun...@qos.ch> on behalf of Ceki Gülcü
<c...@qos.ch>
*Sent:* Wednesday, January 11, 2017 1:00 PM
*To:* logback developers list
*Subject:* Re: [logback-dev] Logback PR #352: Add appender for TestNG
Reporter
Hi Scoot,
Thank you for posting your question on this list.
ReporterAppender is probably not useful enough for a wider audience. As
such, I do not think it is advisable to incorporate it into logback proper.
Best regards,
--
Ceki
On 1/11/2017 21:29, Scott Babcock wrote:
Hi!
My PR #352 (https://github.com/qos-ch/logback/pull/352) was closed,
stating that it’s not generic enough. Given that TestNG is the most
widely used Java testing framework in the world, how much more generic
does a Logback logger need to be for it to be included in the mainline
project?
The primary challenge with spinning this up as a separate project is
that much of the basic building blocks for developing loggers and unit
tests haven’t been defined or published in a form that facilitates
extension and importation of these existing declarations. Consequently,
it’s necessary to duplicate a significant volume of the implementation
from the mainline project into the companion logger project. This is
terribly inefficient and exposes the external project to the risk of
breakage as revisions are applied to the mainline project that aren’t
automatically picked up by the companion project.
Please advise.
Thanks!
= Scott Babcock =
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev
_______________________________________________
logback-dev mailing list
logback-dev@qos.ch
http://mailman.qos.ch/mailman/listinfo/logback-dev
