First, these all started out being called adapters and even had their own Maven groupId. We changed that a few releases ago. Second, although I have no problem using the terminology on the web site I just hate having jar names that long. I don't think it provides any value to them. And I am tired of renaming things for the sake of renaming things.
Ralph On Jul 18, 2013, at 11:40 AM, Nick Williams wrote: > So, again we are at an impasse it would seem. Paul, Gary, Nick, Remko all > want to rename these, Ralph opposes. > > I /kind of/ see where Ralph's coming from here: > > - log4j-slf4j-impl, called "SLF4J Binding," is an actual SLF4J > implementation. The SLF4J team calls them "bindings." This, the name "SLF4J > Binding" does make some sense. However, I would thus submit that the artifact > name log4j-slf4j-binding makes more sense that log4j-slf4j-impl. However, I > still think "Bridge" makes sense here. It's a bridge between the SLF4J API > and the Log4j implementation. Think about it this way: log4j-slf4j-impl isn't > actually an implementation/binding of SLF4J because it doesn't actually write > anything; it's a bridge between the SLF4J API and the Log4j implementation > and takes the place of an SLF4J implementation. > > - log4j-jcl, already called a bridge, Ralph agrees is a bridge. I fail to see > a real difference between bridging the Commons API to Log4j and bridging the > SLF4J API to Log4j. If the Commons Logging team decided to create an > implementation, this bridge component wouldn't actually change. Thus, I > submit, it would still be a bridge. Either way, Ralph agrees it's a bridge > but opposes renaming the artifact as such. > > - Ralph's argument for log4j-1.2-api makes the most sense to me. Unlike the > other two components, which require the SLF4J API JAR and Commons Logging API > JAR, respectively, log4j-1.2-api /replaces/ the Log4j 1.2 JAR. Users DO NOT > and SHOULD NOT include the Log4j 1.2 artifacts on their class path when using > this component. Thus, this really is the Log4j 1.2 API and not a bridge > between that and Log4j 2. > > So then, admittedly later than I should have, I looked up the Bridge Pattern > and the Adapter Pattern. (The Wikipedia articles on these are useful.) Gamm, > Helm, Johnson and Vlissides's "Design Patterns" (1995, Addison-Wesley) says > the Bridge Pattern is meant to "decouple an abstraction from its > implementation so that the two can vary independently." Well, that's not > exactly what's going on in all of these cases. In fact, that really just > describes the relationship between the Log4j 2 API and the Log4j 2 Core. The > Adapter Pattern, on the other hand, translates one interface for a class into > a compatible interface (Freeman, Frooman, Kathy, and Bates. "Head First > Design Patterns." O'Reilly. 2013.). That's not exactly what's going on in all > of these cases, either. > > Based on all this info, if I had to describe these three components to > someone I would do it thusly: > > - SLF4J API Bridge > - Commons Logging API Bridge > - Log4j 1.2 API Adapter > > Based on the "official" definition of these patterns, I think these terms are > accurate. I also think that using the same term for the Log4j 1.2 component > could be a problem, because it may lead users to think they need the old > Log4j JARs just like they need the SLF4J and Commons Logging JARs. However, I > DO think that using a different term for the SLF4J and JCL components could > be just as confusing for users. Therefore, I propose: > > - "log4j-1.2-api" becomes "log4j-1.2-api-adapter" and is named "Log4j 1.2 API > Adapter" (leaving API in named to stress that it replaced Log4j 1 JAR) > - "log4j-jcl" becomes "log4j-jcl-bridge" and is named "Commons Logging API > Bridge" > - "log4j-slf4j-impl" becomes "log4j-slf4j-bridge" and is named "SLF4J API > Bridge" > > That's my $0.02. We're still left with Ralph's opposition, and I'll leave it > up to the big wigs to decide this one. > > Nick > > > On Jul 18, 2013, at 12:13 AM, Ralph Goers wrote: > >> Also, "binding" is the term SLF4J uses for implementations of its API, so >> that should make sense to SLF4J users looking for implementations. Log4j >> 1.2 is an implementation of that API - the "real" log4j 1.x jars should not >> be used. The JCL bridge is exactly that, a bridge between the Commons >> Logging jar and Log4j 2 (the commons logging jar is required). > > On Jul 18, 2013, at 12:07 AM, Ralph Goers wrote: > >> We have already renamed these at least twice. Just leave them be. >> >> Sent from my iPad > > On Jul 17, 2013, at 10:16 PM, Paul Benedict wrote: > >> So much better. >> >> >> On Wed, Jul 17, 2013 at 10:12 PM, Gary Gregory <[email protected]> >> wrote: >> >> On Jul 17, 2013, at 22:40, Nick Williams <[email protected]> >> wrote: >> >>> Yea I think we all go that. Important part is: >>> >>> - "log4j-1.2-api" becomes "log4j-1.2-bridge" and is named "Log4j 1.2 Bridge" >>> - "log4j-jcl" becomes "log4j-jcl-bridge" and is named "Commons Logging >>> Bridge" >>> - "log4j-slf4j-impl" becomes "log4j-slf4j-bridge" and is named "SLF4J >>> Bridge" >>> >>> Consistency is a good thing, and it helps users out by not confusing them. >> >> Yes! Preach on brother :) +1 >> >> Gary >>> >>> Nick >>> >>> On Jul 17, 2013, at 9:35 PM, Remko Popma wrote: >>> >>>> Small correction: I'd like to rename the log4j-1.2-api jar to >>>> log4j-1.2-bridge-2.0.jar (without api in the name). >>>> >>>> >>>> Sent from my iPhone >>>> >>>> On 2013/07/18, at 11:07, Remko Popma <[email protected]> wrote: >>>> >>>>> Currently we have three different names for things that provide a >>>>> bridge/adapter from other logging APIs to the Log4j2 implementation: >>>>> (Commons Logging) Bridge, (Log4j 1.2) API, and (SLF4J) Binding. >>>>> >>>>> Would it be a good idea to call them all "Bridge"? >>>>> >>>>> On the web site, components would then become: >>>>> Commons Logging Bridge, Log4j 1.2 Bridge, and SLF4J Bridge. >>>>> >>>>> The jar files would become: >>>>> log4j-jcl-bridge-2.0.jar >>>>> log4j-1.2-api-bridge-2.0.jar >>>>> log4j-slf4j-bridge-2.0.jar >>>>> >>>>> I would especially like to rename log4j-1.2-api-2.0.jar so we only have >>>>> one jar with "api" in the name. >>>>> >>>>> Thoughts? >>> >> >> >> >> -- >> Cheers, >> Paul > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
