Hi On Thu, Dec 23, 2021, at 14:51, Leo Simons wrote: > Thanks for chipping in Christian! Your detailed notes from back then helped > a ton figure basic things out. > > What I did for the PRs I made is to > > * also check in the 32 bit 1.2.17 dll from the binary release, like was > already done for 64 bit, > * have the maven build not auto-attempt to build it, > * make its single unit test not even attempt to run except on windows, > * add a matrix build that includes running on windows so that the > windows-only test gets run frequently > * did a little test on a windows machine with one of the DLLs > > Basically does for the 32 bit DLL what was already done for the 64 bit DLL. > > I think it’s good enough like that. > > Additional todo could be > * add better INSTALL instructions for how to rebuild the dlls with ant
Definitely. It looked like a waste of time back then with 2.0 approaching. Personally I have no access to a Windows machine. I cannot run the windows build part. Apart from that, I am helping with the release of a 1.2.18, even if it hurts like hell > * add another CI / GitHub action build that rebuilds the DLLs > > I think it is best to produce the DLLs on windows and the official release > on linux, and to not attempt to have build orchestration to glue those > together. It’s an exceptionally messy thing to rebuild from source without > manual step, while the manual step is easy. I think so. I didn't see the PRs though - are they still local on your box? Kind regards, Christian > > Cheers, > > Leo > > > On Thu, 23 Dec 2021 at 14:34, Gary Gregory <garydgreg...@gmail.com> wrote: > >> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier <grobme...@apache.org> >> wrote: >> >> > >> > On Thu, Dec 23, 2021, at 14:05, Gary Gregory wrote: >> > > One of the difficulties was likely related to building the Windows DLLs >> > > for >> > > using the Windows Event Log Appender ( >> > > >> > >> https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/nt/NTEventLogAppender.html >> > ). >> > > I remember that being challenging. I can't recall if we signed the DLLs >> > > like we might do for Apache Commons Daemons Windows binaries. Another >> > > hurdle. >> > >> > Correct, the DLL is even in the codebase. >> > >> > >> https://github.com/apache/logging-log4j1/blob/trunk/NTEventLogAppender.amd64.dll >> > >> > If we would remove that Appender, it would be much easier to build, when >> I >> > remember correctly. >> > Would - in this case - an 1.2.18 with a NoOp NTEventLogAppender be OK? >> > >> >> Sadly, no. We cannot break binary compatibility, that would create a bigger >> mess: Jar hell. Some folks would argue for breaking BC but that's a no-go >> me. >> >> I feel like the projects I've worked on like Apache Commons and >> HttpComponents have benefitted *massively* from providing binary >> compatibility. Giving users drop-in replacements is a huge help. >> >> Recall that Apache officially *only releases source code*, and that source >> code must be buildable, no matter how complex the instructions. Any >> binaries are only provided as a convenience, that includes jar files and >> DLLs. >> >> Gary >> >> >> > > >> > > FWIW, my opinion has been to NOT resurrect 1.x and put our energies >> into >> > > improving the 1.2 bridge and configuration file support we already have >> > in >> > > 2.x. That said, if we decides to move forward with 1.2.18, I'll help. >> > > >> > > No matter what, it needs to be a decision made carefully and not in >> > haste. >> > > >> > >> > +1 >> > >> > > Gary >> > > >> > > On Thu, Dec 23, 2021 at 7:56 AM Christian Grobmeier < >> > grobme...@apache.org> >> > > wrote: >> > > >> > >> Hello >> > >> >> > >> I have been the person cutting the 1.2.17 release and what I remember >> > was >> > >> it was a super hard build. I had to install some VMs because there >> were >> > >> weird dependencies to this build. Building it fully will not be easy, >> > but I >> > >> can also look into some mails whatever I found from that time. >> > >> Here is some build info.: >> > >> https://github.com/apache/logging-log4j1/blob/trunk/INSTALL >> > >> Some unit tests only run with a Windows VM >> > >> >> > >> It would be easier to remove some components, but BC is broken then. >> > >> >> > >> We told people in August 2015 this is EOL. I am honestly surprised >> that >> > we >> > >> discuss a new release after 7 years. To my understanding the >> JMSAppender >> > >> issue is not as critical (just don't configure it). If a >> > reconfiguration of >> > >> system is not on the cards, I wonder if upgrading from 1.2.17 to >> 1.2.18 >> > is. >> > >> >> > >> That said i don't think we should resurrect it. >> > >> >> > >> If somebody really wants to work on, I also don't think we should go >> > >> through the incubator. We can do this using the normal processes and >> > apply >> > >> patches, vote on new committers etc. >> > >> >> > >> My 2 cents. >> > >> >> > >> Christian >> > >> >> > >> >> > >> On Mon, Dec 20, 2021, at 01:36, Gary Gregory wrote: >> > >> > Improving legacy compatibility is what I've been pushing. I agree >> with >> > >> > Matt. IMO resurrecting 1.x sets a bad precedent and is a proverbial >> > can >> > >> of >> > >> > worms. >> > >> > >> > >> > Gary >> > >> > >> > >> > On Sun, Dec 19, 2021, 17:55 Matt Sicker <boa...@gmail.com> wrote: >> > >> > >> > >> >> The alternative is to polish the 1.x compatibility in 2.x which is >> > both >> > >> >> actively maintained and much easier to get releases published. Then >> > >> users >> > >> >> on 1.x can more easily upgrade to 2.x. I can almost guarantee that >> > >> >> regardless of how many warnings we add to a potential 1.x release, >> > we’ll >> > >> >> get inundated with CVE reports, bug reports, and email, all related >> > >> solely >> > >> >> to 1.x which none of us wish to maintain (especially given most of >> us >> > >> >> weren’t even involved in 1.x back when it was in development). >> > >> >> -- >> > >> >> Matt Sicker >> > >> >> >> > >> >> > On Dec 19, 2021, at 16:48, Vladimir Sitnikov < >> > >> >> sitnikov.vladi...@gmail.com> wrote: >> > >> >> > >> > >> >> > Matt>but at least one release using the normal ASF release >> > >> requirements >> > >> >> is >> > >> >> > required to graduate. >> > >> >> > >> > >> >> > Thanks for the reminder, and I am sure preparing the release >> won't >> > be >> > >> an >> > >> >> > issue. I refactored release scripts for both Calcite and JMeter, >> > and >> > >> I am >> > >> >> > sure log4j 1.x is doable. >> > >> >> > >> > >> >> >> compared to the alternatives discussed in this thread. >> > >> >> > >> > >> >> > I must be missing the alternarives. >> > >> >> > Can you please highlight them? >> > >> >> > >> > >> >> > There were multiple suggestions and various PRs from external >> > >> >> contributora, >> > >> >> > yet the committers respond with vaugue messages. >> > >> >> > >> > >> >> > The code must be buildable, so moving to Git, and adding GitHub >> CI >> > is >> > >> the >> > >> >> > mandatory step. >> > >> >> > Of course, the existing PMC members and committers might have >> > >> opinions on >> > >> >> > the way to fix the issues, however I see no reasons for the team >> to >> > >> deny >> > >> >> > Git. >> > >> >> > >> > >> >> > The migration to Git consumes absolutely no resources from >> > committers, >> > >> >> > except a couple of +1 votes. >> > >> >> > >> > >> >> > Unfortunately, even a trivial improvement like Git is ignored by >> > >> Logging >> > >> >> > PMC. >> > >> >> > >> > >> >> > So I take Ralph's suggestion to reestablish the new PMC for log4j >> > 1.x >> > >> >> > seriously. >> > >> >> > >> > >> >> > Vladimir >> > >> >> >> > >> >> >> > >> >> > >>
