Support JetBrains 2024.1 EAP releases

[jansorg]

Closes #535

This adds compatibility with 2024.1 eap. Compilation did not show problems and all tests passed.
I'm waiting for 2024.1 eap3 to be fully published before making this PR available for review.

[apotterri]

@jansorg What's the reason for having ideVersion and ideVersionVerifier? When are each of them used?

[jansorg]

@apotterri ideVersion defines the SDK used for compilation and for tasks like runIde, CI is overriding it with -PideVersion=... to build and test against a specific version.
ideVersionVerifier is used for the JetBrains plugin verifier, which checks binary compatibility for each version contained in this property. Because it's a list we're not using ideVersion here.

[apotterri]

Why does CI override it? When do you choose to change what's in gradle.properties and what's used by CI?

[jansorg]

Please take a look at the GitHub Actions of this repo for the details.
CI is overriding the version for Windows because an earlier version is failing for unknown reasons on Windows with the plugins.

Compilation for releases needs to happen with the earliest version for binary compatibility. That's why it's enabled by default.
Later versions in gradle.properties are enabled locally during development to verify compilation and to test or reproduce a particular issue.

[apotterri]

I have looked at the GH action. It's pretty thin on details, which is why I asked the question.... ;)

Ah, so ideVersion is serving double duty: it's used to specify binary compatibility, but it's also the version that's tested against (unless it's overriden, as for Windows). Would it make sense to add a matrix entry that tests a newer (maybe latest) ideVersion?

I'm asking because I added a test to the agent to ensure that it works with the plugin: https://github.com/getappmap/appmap-java/blob/65b816676a7052fdfa56b5d535a548d0fe107425/agent/test/intellij/intellij.bats#L35C17-L35C41 . It pins ideVersion to a version that failed with 1.26.2, because the oldest ideVersion didn't fail. I didn't feel completely comfortable with the pin, and I wondered if it was the right thing to do.

[jansorg]

Glad to know why you're asking :)

In general ideVersion defines the version of the SDK the plugin is built for. For releases we have to built against the earliest supported SDK, due to binary compatibility.

IMHO we have to run tests at least against the SDK used to compile the published plugin. That's what we're doing now.
We could certainly add a built-matrix, e.g. for the earliest and the latest version (tracking now at #557). I'd appreciate it, unless it's increasing the total runtime of a job.

Regarding your bats-core test:
Because the agent is working fine with the earlier JetBrains SDKs, you'll have to instruct Gradle to use a different SDK. I don't think we should change the default in the plugin because a lot during development requires the earliest version we're supporting.
Pinning the version is okay, but it could become outdated when we're dropping supported SDKs from the plugin.

The possible ways to test with appmap-java I can think of:

1. Run plugin tests in a matrix against a nightly build on appmap-java
2. Run plugin tests in a matrix against, then take upstream appmap-java, build it and use it for our tests
3. appmap-java runs tests against the JetBrains plugin, just like your test

WDYT?

[github-actions]

AppMap runtime code review

Summary	Status
Failed tests	✅ All tests passed
API changes	0️⃣ No API changes
Security flaws	✅ None detected
Performance problems	✅ None detected
Code anti-patterns	✅ None detected
New AppMaps	0️⃣ No new AppMaps

[appland-release]

🎉 This PR is included in version 0.56.0 🎉

The release is available on:

• v0.56.0
• GitHub release

Your semantic-release bot 📦🚀