On Apr 10, 2013, at 8:21 AM, Gary Gregory wrote: > Hi All: > > I find it confusing to have >1 group Id, for example in Ivy, when I tried > > <dependency org="org.apache.logging.log4j" name="log4j-api" > rev="2.0-beta4" /> > <dependency org="org.apache.logging.log4j" name="log4j-core" > rev="2.0-beta4" /> > <dependency org="org.apache.logging.log4j" name="log4j-1.2-api" > rev="2.0-beta4" /> > > it bombed because the 1.2 API is in "org.apache.logging.log4j.adapter" not > "org.apache.logging.log4j" > > What is the point of this complication? It's bad enough we have a bunch of > jars, but multiple group ids? > > Gary
I'll chime in to say, as unbinding as it may be, that I agree with Gary. Many more-complex projects have just a single groupId. Seems to me that different group IDs should exist only for unrelated functionality—in my opinion. I'm all for using the same groupId for all artifacts in Log4j 2. When I created the log4j-taglib component, I left it in the main groupId because it didn't belong in adapter (it's not an adapter ... if anything it's just another part of the API, capable of using any implementation that the primary API is capable of using). It should be noted for anyone not already aware that log4j-1.2-api, log4j-flume-ng, log4j-jcl, and log4j-slf4j-impl all USED to be in the main groupId. They were moved to "adapters" in late 2012. N
smime.p7s
Description: S/MIME cryptographic signature
