Leo, It is still the middle of the night for me so I won’t do anything for several hours. I will create the branch but I am curious about the rest. When I ran the build last night it ran through a bunch of unit tests without any problems. It then failed due to javadoc errors. I just told the plugin not to fail and then it started executing the site plugin. I tried updating the version but that just caused it to have an error in the site.xml.
My question is, you said that the build has test failures. Did I not see them because of the changes after 1.2.17 or is something else going on? Ralph > On Dec 23, 2021, at 2:22 AM, Leo Simons <m...@leosimons.com> wrote: > > (On mobile) > > Cool. > > First I suggest to make a new branch from 1.2.17. Trunk has various stuff > that’s backwards incompatible. Something like > > git checkout -b main v1_0_2_17 > git push -u main > > Then go into GitHub settings and make main the default branch. > > So then people make PRs against that. > > Think someone can take up to a5405370d844fca078c25f66654f929d07b1a922 from > > https://github.com/apache/log4j/pull/17 to make a PR to get to a modern > build. > > With some test failures because I got rid of the limited whitelist of unit > tests. Most of the commits after that set up GitHub actions and fix the > test suite. > > I expect you can safely take everything on that PR17 that is a commit that > does not start with “fix:” without much discussion. > > Each of those “fix:” commits from PR17 should then be a distinct PR and a > discussion, where based on Gary’s feedback most of them have a -1 against > them due to dropping functionality. > > Instead of or in addition to some of those fixes, a nice alternative > approach that Vladimir suggested before is to split off the more > problematic integrations (jdbc,jms,smtp,telnet,plaintext socket) into their > own mini library jars. Then you can replace log4j-1.2.17.jar with > log4j-1.2.18.jar and in the rare(r) cases you do need the other stuff you > add in, say, log4j-jms-1.2.18.jar. Easy to understand, not too much effort. > > The third approach, the one Gary suggested, is to backport (the idea of) > more secure code from 2.x. > > Cheers, > > Leo > >> On Thu, 23 Dec 2021 at 07:34, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >> I have cloned the read-only log4j repo to >> https://github.com/apache/logging-log4j1. >> >> I have followed the build instructions and had to modify the javadoc >> plugin to not fail on errors. Now it fails in the site plugin. >> >> If someone else wants to take this on I would suggest the first PR should >> just to the pom.xml file to get the build working as is. >> >> Ralph >> >> >>
