Ralph, I don't know how to do that either. The best I can do is link my commits.
https://github.com/shawjef3/logging-log4j2/commits/message-location-release-2.x-squashed?author=shawjef3 And then the scala one has only one commit. https://github.com/shawjef3/logging-log4j-scala/commit/dd9a5dd2d6bef80ef4f0334c2ed7043299ddbad <https://github.com/shawjef3/logging-log4j-scala/commit/dd9a5dd2d6bef80ef4f0334c2ed7043299ddbad4> On Mon, Dec 16, 2019 at 11:02 PM Ralph Goers <[email protected]> wrote: > I am having trouble figuring out how to see only what you have changed. > GitHub doesn’t seem to want to let me compare your branch against master at > the point the branch was created. Any ideas? > > Ralph > > > On Dec 16, 2019, at 8:41 PM, Jeffrey Shaw <[email protected]> wrote: > > > > Something I created but didn't push to get included in 2 is the ability > to > > hard code source code locations. This is useful in contexts where the > > compiler can provide them. For instance, Scala's macros can do it. I > > implemented this intending it to improve performance, since run-time > stack > > tracing is no longer necessary. > > > > > https://github.com/shawjef3/logging-log4j2/tree/message-location-release-2.x-squashed > > > https://github.com/shawjef3/logging-log4j-scala/tree/message-location-squashed > > > > On Mon, Dec 16, 2019 at 3:34 PM Ralph Goers <[email protected]> > > wrote: > > > >> I should point out that a lot of the crappy things we did with > interfaces > >> prior to Java 8 can now be undone. Some of it already has been. For > >> example, ExtendedLogger was added so we could add new methods to the > Logger > >> interface. Those can now all be moved to the Logger interface as default > >> methods. But ExtendedLogger still needs to stick around even if it is an > >> empty interface as a lot of code references it. I already did that for > >> LifeCycle2, MessageFactory2, AbstractMessageFactory and possibly others. > >> > >> Ralph > >> > >> > >>> On Dec 16, 2019, at 1:14 PM, Ralph Goers <[email protected]> > >> wrote: > >>> > >>> > >>> > >>>> On Dec 16, 2019, at 12:59 PM, Raman Gupta <[email protected]> > >> wrote: > >>>> > >>>> What is the point of releasing log4j 3.x if you only intend to make > >>>> non-breaking changes? Is it just a marketing thing then? > >>> > >>> We will be significantly impacting the implementation. We are breaking > >> up core into smaller modules. Until we upgraded 2.13.0 to Java 8 we had > >> added stuff to the API that couldn’t be implemented in Java 7. Since > 2.13.0 > >> is now on Java 8 a lot of the new API stuff has been back ported, so I > >> don’t expect much difference there. > >>> > >>> The main driver for 3.0 was always to break it up so that core didn’t > >> have so many optional dependencies. That dove-tailed with JPMS in Java > 9 so > >> that most of Log4j could be proper JPMS modules. > >>> > >>> I have also modified the plugin system to address problems that occur > >> with JPMS in finding them across modules - the plugin system no longer > has > >> a Log4jPlugins.dat file. Instead it generates a class file containing > the > >> plugin definitions which is loaded by the ServiceLoader. > >>> > >>> So 3.0 really will be a significant change. But it should still support > >> anything that was compiled against 2.x. > >>> > >>> Ralph > >>> > >>> > >>> > >>> > >> > >> > >> > > >
