Thanks for taking a look Stephen. I appreciate the guidance. I will be sure to submit a PR when I get something going with Log4j 2.
Ralph > On Apr 21, 2017, at 3:01 PM, Stephen Colebourne <scolebou...@joda.org> wrote: > > Some rules: > - Each module contains a set of packages, each of which must be > specified explicitly. > - Modules depend on other modules, but must not form a cycle of dependencies. > - No package can be in two modules > > Looking at the Javadoc here - > https://logging.apache.org/log4j/2.x/javadoc.html - it seems like each > jar file has a separate set of packages it contains, with an obvious > super-package for each jar file*. Furthermore, the super-packages of > the jar files do not clash, so I think you are fine in naming terms. > What I can't be sure from the Javadoc is whether there is a cycle of > dependencies. > > Possible modules: > - org.apache.logging.log4j > - org.apache.logging.log4j.core > - org.apache.logging.log4j.io > - org.apache.logging.log4j.taglib > - org.apache.logging.log4j.jcl > - org.apache.logging.log4j.jul > - org.apache.logging.log4j.flume.appender > - org.apache.logging.log4j.jmx.gui > - org.apache.logging.log4j.web > - org.apache.logging.log4j.nosql.appender > > * the slf4j bridge is problematic, but is being addressed by changes in slf4j. > * the logf4 v1 bridge probably can't be modularized > > Bernd has addressed the point about the need to export all packages > individually, allowing the modules above. > > Stephen > > On 21 April 2017 at 21:34, Ralph Goers <ralph.go...@dslextreme.com> wrote: >> I am having a hard time figuring out how Log4j is going to be able to >> support this. The API itself is in org.apache.logging.log4j and some >> packages under that. All the main implementation is under >> org.apache.logging.log4j.core. These obviously overlap. Most of our other >> jars have packages that are in org.apache.logging.log4j.xxx where xxx >> matches the jar name. We aren’t going to change the API to support modules. >> >> Is there some reasonable way around this? >> >> Ralph >> >>> On Apr 21, 2017, at 6:16 AM, Stephen Colebourne <scolebou...@joda.org> >>> wrote: >>> >>> On 21 April 2017 at 13:59, sebb <seb...@gmail.com> wrote: >>>> What happens when there is a API break which necessitates a package name >>>> change? >>>> I assume that the module name will also need to change to the new >>>> super-package. >>>> e.g. >>>> >>>> Commons-Lang4 >>>> -> super-package org.apache.commons.lang4 >>>> -> module org.apache.commons.lang4 >>> >>> Yes, thats right. >>> >>>> AFAICT Commons generally has obvious and unique super-packages for >>>> each component. >>>> This should make it easier than for larger projects with lots of jars >>>> and potentially overlapping package names. >>>> >>>> However even Commons has some code that uses a different package structure. >>>> e.g. NET uses examples as the super-package. >>>> This includes working examples that are included in the release. >>>> I guess that will have to change (which is probably a good idea anyway). >>> >>> Yes, as it stands, [net] would be a bad modular citizen, because it >>> exposes the "examples" package, and thus prevents any other module >>> from using that package. Just move it to >>> org.apache.commons.net.examples. >>> >>> Stephen >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
