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 * 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. 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 > > >> >> > > >> >> > > >> > > >
