I think that we should still split up log4j-core though. On Jan 10, 2017 3:18 AM, "Matt Sicker" <boa...@gmail.com> wrote:
> Going to go with the name Log4j Boot. I submitted a git repo request and > the form says it should be created within the hour. > > On 8 January 2017 at 23:13, Apache <ralph.go...@dslextreme.com> wrote: > >> Go for it! >> >> Ralph >> >> On Jan 8, 2017, at 1:44 PM, Matt Sicker <boa...@gmail.com> wrote: >> >> Also, one neat aspect of this that I didn't think of at first is that as >> we trim down log4j-core and the main logging-log4j2 repository, users won't >> need to worry about changing dependencies down the line as the updated >> starters will point to the proper dependencies. >> >> I also have two more starter ideas: >> >> * One that brings in all relevant log4j bridges (slf4j-impl, jul, jcl, >> log4j-1.2) >> * One that brings in all relevant slf4j bridges instead (slf4j-impl, >> jcl-over-slf4j, jul-to-slf4j) similar to the spring-boot-starter-log4j2 >> >> For completeness sake, I'd also be willing to add starters for a few >> trivial things like the various bridges and log4j-api-lang modules, though >> those should work well enough without using a starter (though it could be >> confusing if there is no starter for them). >> >> On 8 January 2017 at 14:26, Matt Sicker <boa...@gmail.com> wrote: >> >>> 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> >>> >> >> >> >> -- >> Matt Sicker <boa...@gmail.com> >> >> >> > > > -- > Matt Sicker <boa...@gmail.com> >
