Good evening, > It is a bit clearer now. I think the discussion boils down to a question > of splitting the work and responsibility. In the current set up, SLF4J is > oblivious to the existence of X4JULI and I would like to keep it that > way. With the changes you propose, given that slf4j-jdk14.jar would > become dual purpose (JUL and X4JULI). Thus, I'd need to test that > slf4j-jdk14.jar > worked with JUL and X4JULI, additional responsibility which at present > time I would like to avoid.
The dual purpose is correct. For JUL and any native combination of JUL and SLF4J. There are not many ways to combine a different interface with JUL than overwriting Logger and supply a different LogManager under the hood. Do you see this as problem of your personal workload? I can provide additional unit tests (not this week anymore) and contribute additional changes for the build process for testing. > Conversely, you would prefer to be unburdened by the need to synchronize > your code with SLF4J without needing to fetch source code from the SLF4J > branch. I propose to review the difficulty of synchronization in a few > months time after we have more hindsight on the matter. Would that be OK > with you? It is o.k. My goal is to keep x4juli in line with slf4j and have good support for it. I will split the jars for x4juli 0.7 to provide slf4j users the freedom of choice between x4juli and safe use of a different sl4fj-xyz-log implementation. Additionally there is a good argument for this strategy - slf4j is nearly production ready and I will not speed up running with x4juli releases, because quality is more important than a 1.0 which has a quality of an bad alpha release. (This is open source, no need for aggressive time to market). Think of JDOM, which had a really long 0.x releases over years. Regards Boris _______________________________________________ dev mailing list [email protected] http://slf4j.org/mailman/listinfo/dev
