Repository navigation
Conversation
Co-authored-by: Ben Durrans <Benjamin.Durrans@snyk.io>
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
Consolidates the duplicate cloud-setup notes into a single AGENTS.md, folding in the useful detail from the parallel branch: the JavaSE-17 target-platform rationale, the `./mvnw package` vs `clean verify` split, the headless-Tycho note and the `-P sign` warning. Adds the verified root cause of the JDK 21 test failures (Mockito 4.5.1 with an explicitly pinned byte-buddy-agent 1.14.1) and the `-Declipse.p2.mirrors=false` flag, which avoids p2 mirror redirects to hosts that cannot be allowlisted. Replaces the fixed reachable/blocked host list with guidance to probe egress directly, since the allowlist changes between runs. Co-authored-by: Cursor <cursoragent@cursor.com>
|
|
Records what it takes to install the built feature into a real Eclipse, which building and unit tests do not cover: the matching 4.34/2024-12 IDE is served only from archive.eclipse.org and www.eclipse.org, which are typically blocked, but the current release is reachable from download.eclipse.org and the 4.34-built plugin runs on it. Includes the p2 director command. Documents that the Snyk view renders through an SWT Browser widget and needs libwebkit2gtk-4.1-0, without which it fails as an opaque ErrorViewPart ClassCastException, plus the -data workspace lock caveat. Documents the authentication gotchas: the token comes from the plugin's own preferences rather than SNYK_TOKEN or the CLI configstore, OAuth2 times out so the API-token method is required, and the plugin applies its own folder-trust gate. Co-authored-by: Cursor <cursoragent@cursor.com>
A saved cloud environment carries a pre-baked ~/eclipse-workspace, and launching against it produces repeated "Enter Password to Unlock the Secure Storage" dialogs: the plugin reads stored credentials while Eclipse's master password was never set. It presents as a plugin fault, and it blocks unattended GUI runs completely. Records the two ways out — dismiss or set a password once when interactive, or use a fresh -data workspace / clear ~/.eclipse/org.eclipse.equinox.security when unattended. Reported by a later cloud run than the one this branch was opened from, so it was missing from the notes this PR already carries. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
"passes 400 tests" is an expectation that rots: the number changes whenever the suite does, and a reader who sees a different count cannot tell whether they have found a real problem or a stale doc. What matters is that the run is clean. The 187-errors-on-JDK-21 figure above is left alone — that is a recorded measurement against named JDK versions, evidence for the diagnosis rather than something a reader is expected to match. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Both archive.eclipse.org and www.eclipse.org were added to the Cursor Cloud egress allowlist on 2026-08-07, so the 4.34/2024-12 IDE the plugin targets can be fetched directly rather than substituting the current release. "Typically blocked" is no longer true and was sending readers to the workaround first. archive.eclipse.org did return a single TLS reset on one run and then served the download on retry, so the note asks for one retry before treating it as blocked. The download.eclipse.org fallback stays, since it does work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The language server skips paths it does not trust and surfaces nothing in the Snyk view, so it presents as a hung scan. Meanwhile the CLI scans the same project in seconds, because it has no trust gate — which makes the plugin look broken. Three Cursor Cloud runs concluded this was a plugin or LS defect and stopped investigating; the Eclipse log had "skipping scan of untrusted path path=…" in it the whole time. Records the tell, and that trust has to go through the plugin: the view's Trust folder affordance, or the trusted-folders list on the Setup tab of Snyk preferences, which sits near the bottom and can be invisible until the window is enlarged. Writing trustedFolders into the LS config file by hand does not work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Two claims here were stronger than the evidence. "Almost always an untrusted folder" was built from a single run's log line. An unanswered Secure Storage prompt produces the same symptom, and a real defect has not been ruled out — the section now describes how to tell them apart and says that a log showing neither is a genuine bug report. It also stops asserting a cause that will be wrong the moment the underlying issue is fixed. "The allowlist changes between runs" is not true: it changes when someone asks an admin, not on its own. The reason not to hardcode a host list is that such a request silently invalidates whatever was written down, which is the point now made. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…roven ones A cloud run on 2026-08-11 instrumented this end to end and reached a working language server, authentication, trust and a real 139-finding scan. The causes are not what these notes claimed. Secure storage: the blocker is an Equinox JavaEncryption.init() race that surfaces as NullPointerException: null algorithm name from SecretKeyFactory.getInstance on the plugin's first encrypted write. Pre-seeding the keyring with cipher and key-factory metadata avoids that path. Neither gnome-keyring nor DBUS_SESSION_BUS_ADDRESS is sufficient alone, and neither is needed once the keyring is seeded — the previous advice to fix this with a fresh workspace or by clearing secure storage did not work. New, and previously undocumented: the language server shells out to bash --login -i -c printenv, which takes SIGTTIN and stops indefinitely when there is no controlling terminal, so no scanner ever starts. SNYK_LS_DISABLE_SHELL_ENV_LOADING=1 avoids it, at the cost of the LS inheriting only the launcher's PATH — which is why Maven projects then fail dependency extraction with child exit -2. Also records that the Re-authenticate dialog defaults to OAuth and offers no token at all, and gives the exact Trust settings path, which only renders once the LS is up. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The whole docs.snyk.io/scm-ide-and-ci-cd-integrations/ tree now 404s, taking the folder trust, authentication and "secure your Eclipse projects" links with it. All three verified dead; the developer-tools/integrations/ equivalents verified live. Note folder trust also changed slug, from folder-trust to eclipse-plugin-folder-trust. Found by a Cursor Cloud agent following the README to set the plugin up, which is a decent argument for a link check in CI. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Same dead tree as the previous commit: the supported-versions link and the troubleshooting link. Both verified 404; both developer-tools/integrations/ equivalents verified live. No scm-ide-and-ci-cd-integrations URLs remain in the repo. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
These two commits fixed dead docs.snyk.io links in README.md. That is unrelated to the Cursor Cloud AGENTS.md notes this PR carries, and it should not have to wait on this PR's review. Moved to a dedicated branch and PR. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…obber Two more findings from the 2026-08-11 cloud run, both cheap to hit and expensive to diagnose. Forcing defaultPasswordProvider turns out to be unnecessary — the default is fine once the keyring is seeded — so this now says to leave it alone rather than implying a provider needs choosing. Adds the two idempotency rules that bit that run: guard the keyring write so a non-empty file holding encrypted credentials is never clobbered, and de-duplicate eclipse.ini arguments because the first occurrence of each wins. Separately: running the Tycho test suite replaces ~/.snyk/snyk-linux with a small test artifact, after which the next launch reports the LS protocol as unknown and does not start. That cost real debugging time and is not obvious from the symptom. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A setup script that ran `eclipse -version` to read the version blocked on a full GUI launch instead of printing and exiting. Point contributors at the install metadata instead.
The Preferences page's trust controls don't render until the snyk-ls language server is running. This was previously only documented on a shared cross-repo Confluence setup page as a generic tip, but it's specific to this plugin's Preferences UI, so it belongs here instead. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
…loud-env-setup-notes-ca2c AGENTS.md add/add conflict: both sides independently created this file. Resolved by combining, not taking either side wholesale -- kept main's real repo-specific content (Project Overview through Development Workflow, added by #451) in full and appended this branch's Cursor Cloud section after it, rather than letting either replace the other.
rrama
force-pushed
the
cursor/cloud-env-setup-notes-ca2c
branch
from
September 4, 2026 13:37
6bb8455 to
8bfae9c
Compare
…p-notes-ca2c # Conflicts: # AGENTS.md
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
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.
Description
Adds an
AGENTS.mdfor this repo. It points at the existing guidance (README.md,CONTRIBUTING.md and
.cursorrules) rather than restating it, then records theCursor Cloud environment notes an agent needs to build and exercise this Maven/Tycho plugin in a
Linux VM. Documentation only — no plugin code changes.
It covers:
./mvnw packageversus the CI./mvnw clean verify -DtrimStackTrace=false, andthat
-P signmust not be passed because it needs signing certs.-Declipse.p2.mirrors=false, which stops Tycho following p2 mirror redirects out to arbitraryuniversity and ISP mirrors that cannot be enumerated in an egress allowlist.
things that bite when you try it.
Worth a reviewer's attention
The JDK 17 requirement is currently undocumented anywhere in the repo. A developer whose default
javais 21 gets 187 opaqueMockitoException: Mockito cannot mock this class …errors across 20+test classes, with no hint as to why.
tests/pom.xmlpins Mockito 4.5.1 and pins the inline mockmaker's agent directly at
net.bytebuddy:byte-buddy-agent:1.14.1, which predates JDK 21 — sobumping Mockito alone would not lift it, both coordinates would have to move. Measured 0 errors on
Temurin 17, and reproduced on macOS rather than only in a cloud VM. This PR only writes the
requirement down for agents; making it discoverable for humans (README, or a fail-fast enforcer
rule) or moving to a JDK-21-capable Mockito/ByteBuddy is a separate change.
Three failure modes when launching a real Eclipse, none of which names its cause. The Snyk view
renders through an SWT
Browserwidget, so withoutlibwebkit2gtk-4.1-0it dies asSWTError: No more handles …, surfacing as aClassCastExceptiononErrorViewPart. The4.34 / 2024-12 IDE the plugin targets is served only from
archive.eclipse.organdwww.eclipse.org, which are typically blocked — but the current release is reachable fromdownload.eclipse.organd the 4.34-built plugin runs on it fine, so this is a non-blocker once youknow it. And on a saved cloud environment the pre-baked
~/eclipse-workspacetraps you in arepeating "Enter Password to Unlock the Secure Storage" dialog, because the plugin reads stored
credentials while the master password was never set — which blocks unattended runs completely.
Deliberately no brittle specifics. No reachable/blocked host list: the egress allowlist changes
between runs, so a fixed map goes stale and gets trusted anyway. Readers are told to probe directly,
and to expect a block to surface as an opaque "Connection reset" during target-platform resolution
rather than as a DNS failure. Likewise no "passes N tests" figure, since that rots as the suite
changes and leaves a reader unable to tell a real problem from a stale doc. The 187-errors-on-21
measurement above is kept, because it is evidence for a diagnosis against named JDK versions rather
than something a reader is expected to match.
Two duplicate cloud-setup PRs had been opened against this repo by successive cloud runs. This one
carries the consolidated content and #443 has been closed as superseded, leaving a single PR per
repo.
Checklist
Screenshots / GIFs
n/a — documentation only.