Update build system

[fluffynuts]

• Updates build system to use gulp-based build
• builds .nupkg and release binaries zip

latest build is here: https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32915894

I'm sure there's more to the Apache release process that I need to learn about, so I'm raising this now to get the ball rolling.

In particular, I', not sure how to:

• sign the CLA
• raise an issue in JIRA (I can't find lo4net in the project list)
• ?? (there's probably other steps I don't know)

[rgoers]

For the CLA see https://www.apache.org/licenses/contributor-agreements.html. In particular you need to fill out the ICLA and send it in according to the instructions. That is a prerequisite to becoming a committer.

Jira was disabled for Log4Net when the project was moved to dormant status. We will request it be reactivated as part of the release.

I see the build log but I can't tell if that is a valid release or not. Java development builds normally have -SNAPSHOT in the version and then the release does not.

The main steps involved in a release are:

1. Tag the source with the release number.
2. Build the binaries from the tagged source (believe it or not, this step is actually optional although most users expect to not have to build it themselves)
3. Create an archive and/or zip of the source and binaries.
4. Sign and checksum the archives and zips.
5. Upload the archives, signatures, and checksums to the ASF dev distribution area (must be performed by a PMC member)
6. Send a Vote email on the release identifying the component, version and changes present in the release. Much of this will be used as the basis for the announcement email after the release is finished.
7. If the vote passes the archives, signatures and checksums are moved to the ASF release distribution area (must be performed by a PMC member).

Updating the web site will most likely be part of the release process, but when and how it is updated is up to the team. However, the Apache announcement list requires that the download link be included near the front of the announcement email and it has to work. Sending an announcement to the announcement email is desirable but is not required. The email must be sent to the asf mail relay using an @apache.org email account. The announcement can also be posted to the ASF Logging blog.

Finally, when the release passes you would want to upload the binaries to where users would most likely consume it, if that isn't from the ASF distribution directories.

[rgoers]

How can I validate this PR? Are there build instructions somewhere? I assume it requires Windows? Any particular version required? Are there prerequisites that have to be installed? A BUILDING.md file would be helpful.

[fluffynuts]

@rgoers good idea about standalone build instructions. I've added a BUILDING.md document which should hopefully be helpful. Feedback appreciated.

[fluffynuts]

Hi

I'll be honest: friction to getting a PR merged in as a non-Apache dev is really daunting. I keep putting it off, but I'm not sure if I'm ever going to get around to ticking all the boxes, crossing all the T's and dotting all the I's. I feel like a flake, but really, I'm just another human being with a limited number of keystrokes they can make in their lifetime.

This, to me, feels like a failing of the process: when the most difficult thing you ask of contributors is to follow some internal processes that, really, don't matter to the project.

The binaries aren't signed -- what is the point of any of the hullabaloo preceding that? Perhaps it matters for Apache Java stuff, but the pretense of that mattering for log4net was dropped the moment signing was dropped -- and really, I don't mind that signing was dropped: nuget.org provides enough verification of valid binaries, imo. None of my libraries are signed, and I'm ok with that.

I don't want log4net to die -- I specifically picked this up to keep a useful library going -- but I'm wondering if this is something I can even make a meaningful difference in.

I've also really struggled in this process to find definitive direction as to exactly how things should get done. Some say Apache Jenkins is where build & release should happen. Others say external CI (like AppVeyor) is fine, but CircleCI apparently isn't. When I get build pipelines in place to support AppVeyor and (if it were accepted), CircleCI, I read that many releases are done from dev machines -- so why did I spend the many many hours on learning the flows for external CI pipelines & working out the kinks so they actually worked? Log4Net holds a lot of legacy support -- getting that to work in an arbitrary build environment is non-trivial, but, at the end of the day: worth it -- the build I've proposed still gets log4net out to .net 2.0 and CF targets! On AppVeyer! An environment I have very little control over! And using docker! I learned enough docker to be dangerous enough to get build for ancient .net-supporting systems to actually work!

I see a couple of courses of action here:

1. Someone convinces me that the steps required to contribute to log4net are not as daunting as I think they are, that I'm just really mistaken about the hurdles I perceive; and I strive ahead.
2. I leave this where it is, and this is just part of the fizzle of log4net dying
3. I fork, because I can, and follow agile principles, performing regular, small releases, as and when it makes sense. I would need to know that anyone actually cares for me to do this before trying as it carries with it the all of the responsibility and at least 1/2 the work involved in (1), but at least I'd have the freedom to automate releases and perform incremental releases at the drop of a hat, as I do with my own libraries.

If the world has moved on, so be it, but if the 33 other outstanding PRs against apache-logging/log4net are important to anyone, I need to know before I sink even more hours into this.

[rgoers]

Ironically, I was just looking at the BUILDING.md file. I occasionally use my Windows VM to test the build of Log4j but nothing more than that. I haven't done anything with .NET in years. So the idea of downloading and installing Visual Studio and .NET just to verify the PR makes me think it isn't worth it and I should just merge it after giving it a once-over, which I have done. I admit I am not familiar with much of what it is doing so my review isn't worth much.

[rm5248]

For Ralph: If you don't know, Microsoft does provide development VMs that already have the tools installed so you don't need to download Visual Studio and .NET: https://developer.microsoft.com/en-us/windows/downloads/virtual-machines/

[fluffynuts]

Uhm... so ok, this is merged, but how does a release now get out? 2.0.9 has been ready for release for a while, without happening, long before I got involved. It's all well and good that the project can be easily built -- what's next? Code has no value (imo) if there's no artifact that can be used -- in this case, a nuget package for download.

On the topic of build: if you're not on windows there's the AppVeyer build, which seems to work satisfactorily; if you are on windows, the vs build tools installer is enough -- you don't need all of VS. I don't have all of VS installed, since I prefer to work in Rider. I install the VS Build Tools only. I also figured out a docker environment which should work (https://hub.docker.com/repository/docker/davydm/net-build-tools) -- but it looks like I never made build targets for it :/

On the topic of maintenance: if log4net needs a maintainer and the requirement is to jump through the Apache hoops, I'll do it. What I need (and I have asked before) is some specific direction. Does Apache log4net need a new maintainer? Would I be useful to the project? I'm happy to be a flyby contributor, but I'm also happy to get more involved, if I understand what's required of me to do so.

[rgoers]

To get a release out someone needs to create whatever the PMC is going to vote on. If it is just a source release then that should be packaged in gzip and/or zip format. If the release will contain binaries package them to. If the release is going to be published to some central repo (like Maven Central for Java) that should be done after the release is approved but the PMC needs to review whatever will be pushed to those locations.

We don’t care where you publish the release artifacts for us to review as long as we can get to them.

You would probably want to create a PR with for the git tag for the release candidate.

[fluffynuts]

@rgoers there are release artifacts for this PR, as mentioned in the initial request, at https://ci.appveyor.com/project/fluffynuts/logging-log4net/builds/32915894/artifacts

• nuget package
• source archive

I'm not sure what else to do? I have seem emails on the mailing list to do with voting on a release -- should I be starting one of those?

[TimSirmovics]

Not that this is really the place to comment, but can I just say that there are probably many people who would love a new log4Net version updated for .NET Standard 2.0.
If we can get past this seemingly daunting task of getting updates through to the project and updated packages on NuGet, myself and i'm sure many others would be very appreciative.

[rgoers]

@fluffynuts I see a nuget package and a file named log4net-binaries. I downloaded that and it does not contain source. It looks like a binary distribution. if it is it is missing a LICENSE and NOTICE file. Those are in the root directory of the project and need to be in the source and convenience binaries. I can see that the nuspec file has a link to the ASF license. I assume that placing it there will cause nuget to display that as the license for the artifact?
FWIW, the source and binary archive are going to be hosted at https://dist.apache.org/repos/dist/release/logging/log4net/ in accordance with the ASF release policy. I will be happy to sign them and place them in the dev location once we also have the source archive. Again, please create a PR to push the tag for the release candidate.

[fluffynuts]

@rgoers thanks, I'll create a new PR to rectify: the release should have a source artifact. You're correct about the licensing field in the nuspec, insofar as the link will be presented the the consumer to follow at their convenience.

[fluffynuts]

@rgoers I've created #61 - hope I've done the right thing(s); please let me know if there's something I'm missing.

[cremor]

@fluffynuts I've just updated a few of my projects to log4net 2.0.9. First of all, thanks for your work! But I have to report a few problems and oddities:

Breaking change
One project that compiled fine before doesn't compile any more now. So there is a breaking change in 2.0.9. It's a netcoreapp3.1 project, so it uses the new netstandard2.0 assembly of log4net now (and previously used the netstandard1.3 assembly). The error is 'DebugAppender' does not contain a definition for 'ImmediateFlush'.
Seems like this is caused by your addition here

logging-log4net/src/log4net/Appender/DebugAppender.cs

Line 79 in 8178e51

#if !NETSTANDARD1_3 // System.Diagnostics.Debug has no Flush() in netstandard1.3

which is triggered because the netstandard2.0 target also defines that constant here

logging-log4net/src/log4net/log4net.csproj

Lines 57 to 58 in 8178e51

	<PropertyGroup Condition="'$(TargetFramework)'=='netstandard2.0'">
	<DefineConstants>NETSTANDARD;NETSTANDARD1_3;NETSTANDARD2_0</DefineConstants>

I can see that ImmediateFlush would have had no effect in previous versions (because the if statement in the Append method had the target framework condition), but with netstandard2.0 this should be possible.

So at least the netstandard2.0 assembly should contain that property (and maybe other properties that received a similar change in 2.0.9?). I assume this should be fixed by removing the NETSTANDARD1_3 constant from the netstandard2.0 target. Unless this would cause it to loose other things, I haven't checked that!
To prevent breaking changes the netstandard1.3 assembly should still contain it too. Or, if breaking changes are ok, it could be left removed there.

Dependencies
The nuspec file in the version 2.0.9 NuGet package contains a long list of dependent packages for the .NETStandard2.0 target group. I'm not 100% sure about this, but this shouldn't be needed, right? Because .NET Standard 2.0 referes to the whole API anyway (unlike 1.x versions did).

I think this dependency list is the reason why my netcoreapp3.1 project still needs the <NoWarn>$(NoWarn);NU1605</NoWarn> workaround to prevent errors like Detected package downgrade: System.Net.NameResolution from 4.3.0 to 4.0.0. Reference the package directly from the project to select a different version. during publish of the project. This workaround should not be needed any more with a netstandard2.0 target of log4net.

Assembly attributes
The netstandard2.0 assembly uses "Apache log4net for .NET Core 1.0" as AssemblyTitleAttribte and "2.0.9.0-.NET Core 1.0" as AssemblyInformationalVersionAttribute.

PS: Sorry if this is not the right place to report issues, but I couldn't find a better one. It seems like the log4net Jira is not used any more and issues are not enabled in this GitHub project.

[jvz]

Filed https://issues.apache.org/jira/browse/INFRA-20802 to re-open the Jira tracker. Thanks for the reminder!

[cremor]

@jvz Thanks. Does this mean I should create tickets for the points in my last comment?

[fluffynuts]

@cremor could you see if the changes here fix this: #63

Perhaps:

1. clone the PR branch
2. build (if you have node, npm run build-release)
3. copy the binaries over the ones you're getting from nuget (how depends on how your project is set up, either in the packages folder in the solution or in your .nuget/packages folder in your home / profile folder

alternatively, unpack the .nupkg I attach here (zipped because GitHub wouldn't accept the .nupkg) -- it's built from that branch.
log4net.2.0.9.nupkg.zip

Then rebuild your project

I see that @NicholasNoise fixed up a bunch of things in there and enabled multi-platform testing, so perhaps these binaries work for you. If they do, I'll accelerate incorporation of that PR (there are some things that need to be sorted out, but I could merge, fix & then release)

[cremor]

@fluffynuts Thanks for the pointer to #63 and for the precompiled NuGet package from that PR! I just tested it and it indeed fixes all of the points I mentioned above.

edit: Ok, the breaking change for the removed ImmediateFlush property in .NET Standard 1.3 is not fixed. But I think that's ok since it was not functional anyway.

[NicholasNoise]

Ok, the breaking change for the removed ImmediateFlush property in .NET Standard 1.3 is not fixed. But I think that's ok since it was not functional anyway.

I have failed to find a good way to test DebugAppender compiled for netstandard2.0, because there are no Debug.Listeners despite documentation remarks:

The Listeners collection is shared by both the Debug and the Trace classes; adding a trace listener to either class adds the listener to both.

But actually Debug.Write method does not use Listeners, so there are no way to test... I recommend to replace DebugAppender for TraceAppender.

[cremor]

I'm using the DebugAppender to get my logs to the Visual Studio output window. This works fine for me (both with the old .NET Standard 1.3 log4net assembly and with the new .NET Standard 2.0 one).

ImmediateFlush seems to be not relevant for this use case since all log lines are immediately visible in the output window, even if ImmediateFlush is false.