I think I have a decent idea on how to handle the optional dependencies confusion without needing to split off log4j-core into a zillion submodules. The idea is inspired by the spring-boot-starter-* packages that give you a dependency that's just a pom.xml file (along with some META-INF files, but that would be irrelevant here) that pull in the required dependencies for a feature. So, for example, we could make up a bunch of log4j-starter-* modules that contain pom.xml files to pull in all necessary dependencies for a particular optional feature. Examples:
[all modules would start with the prefix "log4j-starter-"] * async (for AsyncLogger; brings in LMAX disruptor) * config-json * config-yaml * script-groovy * layout-csv * layout-jansi (for windows users and coloured log messages) * layout-json (unless this has been ported to not require jackson anymore?) * layout-xml * layout-yaml * appender-async-conversant * appender-async-jctools * appender-cassandra * appender-couchdb * appender-jms * appender-jpa * appender-kafka * appender-mongodb * appender-smtp * appender-zeromq (or jeromq?) I may have missed a few, but the base set of starters should at least correspond to all optional dependencies in log4j-core or the addon modules. For the jms, jpa, and smtp appenders, we could either make add in a default provider (e.g., ActiveMQ, Hibernate, and Sun Mail respectively) or split those into provider-specific starters. Ideally, these starters would live in their own repository (logging-log4j-starters), and the groupId can be either org.apache.logging.log4j (I think that'd get confusing when searching on maven.org) or org.apache.logging.log4j.starter(s). So what do you think? -- Matt Sicker <boa...@gmail.com>
