I suggest reviewing commit by commit, and skipping the second and last third commits as they are fairly mechanical.

@sharwell @richlander @ChrisSfanos

Are we going to handle non cs files later?

Are we going to handle non cs files later?

The Find and Replace step got them. I did a git grep Apache and walked through the results, and AFAICT, everything remaining after this is redists of other cases (like jquery).

Oh, probably the second commit, which we can't really look at :D

Yes, that's my expectation.

git show 3dbb4f19f6 --name-only | findstr .java | measure-object confirms it (and other extensions too)

Looks like this wasn't done properly:
https://github.com/dotnet/aspnetcore/blob/e954b6aef98408a7b672c7ce31e8dad0b24345f8/src/SignalR/clients/java/signalr/build.gradle#L34-L36

#yolo approval. I can't quite review all the files, but the general gist of it seems right.

@Pilchie I would recommend starting starting the editorconfig rule as a suggestion and doing a second pass that turns in to warnings and clearing up the build warnings. Less chances that you run in to perpetual file conflicts that way.

@dotnet/aspnet-build Looks like some provisioning failures here. What's the best way to re-run?

/azp run

It's green - going to merge!