Fwiw, this sounds like a god plan to me. Ralph
> On Dec 23, 2021, at 6:51 AM, Leo Simons <[email protected]> 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 > * 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 <[email protected]> wrote: >> >> On Thu, Dec 23, 2021 at 8:20 AM Christian Grobmeier <[email protected]> >> 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 < >>> [email protected]> >>>> 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 <[email protected]> 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 < >>>>>>> [email protected]> 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 >>>>>>> >>>>>>> >>>>> >>> >>
