One of my biggest bikeshedding questions I've been thinking about here is: do we call it Log4j2 3.x or Log4j3?
On a more serious note, yes, I'd love to see the config parsing stuff redone. I like using YAML over JSON or properties files, that's for sure, though XML can be nicer when the XSD has enough information for editors to discover everything. Whether we rely on dependencies, shading/repackaging, or a custom API, however, is an interesting discussion. Perhaps if we also tackle autoformatting everything and enforcing a checkstyle config or similar, that would make it easier to maintain multiple branches in the future for backporting bugfixes or security fixes. On Mon, 5 Nov 2018 at 15:01, Gary Gregory <[email protected]> wrote: > Considerations for 3.0: > > - Currently targeting Java 8, seems OK to keep this for now. > - Remove deprecated code > - Make BC-breaking changes as we see fit to improve impl. > - ? Update root package to include "3" to allow Log4j 1, 2, and 3 to > co-exist peacefully on the claspath. Perhaps org.apache.logging.log4j3. > - Do we need a compatibility layer for 1.2 to 3.0 and 2.x to 3.0? > - Where can we use java.time? > - Is it a goal to have Maven modules with NO optional dependencies? I think > so. > - Play nice in the Java 9 module system > - Continue to break up current Maven modules > - How can we make Core smaller? > - Should we redo our config code to use something like Jackson or Commons > Configuration? We have a lot of config code... Not sure if everything you > can do in XML is doable in JSON and YAML. YAML is gross IMO but some people > like it. > > What else? > > Gary > -- Matt Sicker <[email protected]>
