Repository navigation
Ship the logging adapters for .NET Framework again - #6
Merged
Merged
Conversation
IKVM 8.16.0 ships lib/net472 alongside ref/net6.0 and ref/net8.0, so .NET Framework is a platform it supports. The modernization took these two libraries from net461;netcoreapp3.1 to net8.0 alone, which drops every Framework consumer IKVM still serves. That constraint binds harder here than in the Calcite repositories. These are general IKVM extensions -- the audience is anyone running Java code under IKVM -- so inheriting a net8.0-only floor from a Calcite stack narrows them for a reason that is not theirs. Both libraries now build net472;net8.0, and neither needed a source change. Nothing is on nuget.org yet, so widening costs nothing now and would be a consumer-visible change after 1.0.1 ships. The test projects stay on net8.0;net10.0. A net472 test leg does not currently run: IKVM's native library is not resolved on .NET Framework without an explicit RuntimeIdentifier, so every test fails at IKVM.Runtime.LibIkvm with "Could not load ikvm native library", and net472 cannot run on the linux and osx legs of the CI matrix at all. So net472 is shipped but unexercised, which is worth fixing separately and deliberately rather than by bolting a Windows-only leg onto a cross-platform matrix. Verified: both libraries produce net472 and net8.0 output, Slf4j.Tests 20 passed and Java.Util.Tests 21 passed on each of net8.0 and net10.0.
The build runs on ubuntu-24.04, and adding net472 to the two libraries broke it: error MSB4018: The "IkvmCompiler" task failed unexpectedly. Failed to start a process with file path 'mono'. ... No such file or directory IKVM picks the importer by target rather than by host. IKVM.MSBuild.targets sets IkvmToolFramework to net472 for any target framework compatible with net461, so the net472 leg is compiled by the .NET Framework build of ikvmc, and on Linux that runs under mono. The ubuntu-24.04 image no longer carries one. Install it rather than override the choice. Forcing the net10.0 importer would be reaching past a decision IKVM makes deliberately about which tool emits a Framework assembly, and the output is the shipped package. Only the build job needs this. The tests stay on net8.0;net10.0, and the release job packs artifacts it downloads rather than compiling anything. This did not reproduce locally: on Windows the net472 importer runs natively, so both libraries built clean there.
ikvmnet/ikvm installs mono-runtime and mono-devel on ubuntu-24.04 for the same reason, and purges mono-complete while stripping the image down, so asking for mono-complete here was against the practice of the repository this one follows. The pattern is an install step rather than a prebuilt image: ikvm-github-images carries only ubuntu-18.04 and ubuntu-20.04 configs, was last touched in 2022, and nothing here runs on it. Baking mono into an image would mean reviving that repository first.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
IKVM 8.16.0 ships
lib/net472alongsideref/net6.0andref/net8.0— .NET Framework is a platform it supports. The modernization took both libraries fromnet461;netcoreapp3.1tonet8.0alone, which drops every Framework consumer IKVM still serves.That constraint binds harder here than in the Calcite repositories. These are general IKVM extensions — the audience is anyone running Java code under IKVM — so inheriting a
net8.0-only floor from a Calcite stack narrows them for a reason that isn't theirs.Change
IKVM.Extensions.Logging.Java.Utilnet8.0net472;net8.0IKVM.Extensions.Logging.Slf4jnet8.0net472;net8.0No source change was needed for either.
Nothing is on nuget.org yet —
Java.Utilis still on0.1.9from 2023 andSlf4jhas never been published — so widening costs nothing now. After1.0.1ships asnet8.0-only it becomes a consumer-visible change.What this does not do
The test projects stay on
net8.0;net10.0, so net472 ships unexercised. Two things block a net472 test leg, and neither should be waved through inside this PR:RuntimeIdentifier. Withnet472added to the test projects, all 20 slf4j tests fail atIKVM.Runtime.LibIkvmwithCould not load ikvm native library.linux-x64,linux-arm64orosx-arm64legs of the CI matrix at all, so adding it naively turns three quarters of the matrix red.Doing it properly means a Windows-only test leg with a RID, which is a deliberate CI change rather than a side effect of retargeting. Worth its own PR.
Verification
net472andnet8.0outputIKVM.Extensions.Logging.Slf4j.Tests— 20 passed on each of net8.0 and net10.0IKVM.Extensions.Logging.Java.Util.Tests— 21 passed on each of net8.0 and net10.0🤖 Generated with Claude Code