On Fri, Sep 25, 2015 at 5:09 PM, Gilles <gil...@harfang.homelinux.org> wrote:
> On Fri, 25 Sep 2015 07:28:48 -0700, Phil Steitz wrote: > >> On 9/25/15 7:03 AM, Gilles wrote: >> >>> On Fri, 25 Sep 2015 15:54:14 +0200, Thomas Neidhart wrote: >>> >>>> Hi Ole, >>>> >>>> for a start, I think you are asking the wrong question. >>>> First of all we need to agree that we want to add some kind of >>>> logging >>>> facility to CM. >>>> If the outcome is positive, there are a handful of alternatives, >>>> some of >>>> them more viable than slf4j in the context of CM (e.g. JUL or >>>> commons-logging). >>>> >>> >>> Could someone summarize why those alternatives were deemed "more >>> viable"? >>> >>> btw. the same discussion has been done for other commons >>>> components as >>>> well, and the result usually was: do not add logging >>>> >>> >>> What was the rationale? >>> >> >> Look at the archives. We have discussed this multiple times in the >> past in [math] and each time came to the conclusion that Thomas >> succinctly states above. What has changed now? >> > > We also discussed several times to stick with Java 5. > Fortunately, that has changed. [Although sticking with Java 7 is still > a bad decision IMHO.] > > As for logging, IIRC, the sole argument was "no dependency" because > (IIRC) of the potential "JAR hell". > that's not correct. The decision to not include any dependencies has nothing to do with "JAR hell". In order to prevent JAR hell, commons components strictly stick to the "Versioning guidelines" [1] The no-dependency rule is more related to the proposal of the component, see [2] [1] http://commons.apache.org/releases/versioning.html [2] http://commons.apache.org/proper/commons-math/proposal.html Thomas > If there are now well-formed answers proving that the fear was > unfounded, that is also a change. > > IMO, logging is quite important for any "non-obvious" code.[1] > [I'm again stating that, in that respect, CM is not like the other > "Commmons" components.] > > Several times, I've been obliged to create a modified version of CM > to introduce "print" statements (poor man's logging!) in order to > figure out why my code did not do what it was supposed to. > It also makes a code easier to debug while developing or modifying it > (without resorting to poor man's logging, then deleting the "print", > then reinstating them, then deleting them again, ad nauseam). > > Gilles > > [1] No quality or complexity judgment implied. > > > Phil >> >>> >>> >>> Gilles >>> >>> Thomas >>>> >>>> >>>> On Fri, Sep 25, 2015 at 3:17 PM, Ole Ersoy <ole.er...@gmail.com> >>>> wrote: >>>> >>>> Hello, >>>>> >>>>> We have been discussing various ways to view what's happening >>>>> internally >>>>> with algorithms, and the topic of including SLF4J has come up. >>>>> I know that >>>>> this was discussed earlier and it was decided that CM is a low >>>>> level >>>>> dependency, therefore it should minimize the transitive >>>>> dependencies that >>>>> it introduces. The Java community has adopted many means of >>>>> dealing with >>>>> potential logging conflicts, so I'm requesting that we use SLF4J >>>>> for >>>>> logging. >>>>> >>>>> I know that JBoss introduced its own logging system, and this >>>>> made me a >>>>> bit nervous about this suggestion, so I looked up strategies for >>>>> switching >>>>> their logger out with SLF4J: >>>>> >>>>> >>>>> >>>>> >>>>> http://stackoverflow.com/questions/14733369/force-jboss-logging-to-use-of-slf4j >>>>> >>>>> >>>>> The general process I go through when working with many >>>>> dependencies that >>>>> might use commons-logging instead of SLF4J looks something like >>>>> this: >>>>> >>>>> >>>>> >>>>> >>>>> http://stackoverflow.com/questions/8921382/maven-slf4j-version-conflict-when-using-two-different-dependencies-that-requi >>>>> >>>>> >>>>> With JDK9 individual modules can define their own isolated set of >>>>> dependencies. At this point the fix should be a permanent. If >>>>> someone has >>>>> has a very intricate scenario that we have not yet seen, they >>>>> could use >>>>> (And probably should use) OSGi to isolate dependencies. >>>>> >>>>> WDYT? >>>>> >>>>> Cheers, >>>>> - Ole >>>>> >>>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
