fix bazel: prefer .bazelbsp/.bazelproject and fix import/jdeps issues

[tboernerapex]

Summary

• When a persisted project view path points to a root-level .bazelproject, override it to use .bazelbsp/.bazelproject if the latter exists — ensuring the plugin-managed file always takes precedence on sync
• Pre-refresh imported .bazelproject files into IntelliJ's VFS before PSI parsing so that import directives resolve correctly on first open of a large monorepo (without this, the import silently fails and the sync falls back to the entire workspace)
• Fix conflicting Bazel actions when two java_test targets in the same BUILD package share the same basename: use sibling = raw_jdeps_file in declare_file so each materialized .jdeps file lands next to its source rather than colliding in the package root

Test plan

• Open a monorepo with .bazelbsp/.bazelproject that imports a package-level .bazelproject; verify sync only indexes the directories listed in the import chain, not the whole workspace
• Verify that a project with two java_test targets sharing the same simple name in the same package no longer fails with a conflicting actions error during BSP sync
• Verify that previously persisted root-level project view paths are transparently overridden by .bazelbsp/.bazelproject on next sync

🤖 Generated with Claude Code

[tboernerapex]

Klaus Aehlig (@aehlig) I reverted my change.

[Klaus Aehlig (aehlig)]

Klaus Aehlig (@aehlig) I reverted my change.

Thanks. My commit is now available as c9752e0

[tboernerapex]

Klaus Aehlig (@aehlig) do you have comments on these fixes?

[Klaus Aehlig (aehlig)]

tboernerapex Concerning the jdeps-related changes, as mentioned, I'm hesitant to move away from shared actions unless there is at least one example where they don't work as they should .

Concerning the first two commits, I'm sure Evgenii Pasynkov (@noxvost) will review them, as requested by Justin Kaeser (@jastice).

[Evgenii Pasynkov (noxvost)]

Which problem does this commit solves? Why should we prefer the project view from .bazelbsp? IMHO all .bazelproject paths except for repo root are some legacy artefacts and shouldn't be considered in future

[tboernerapex]

Concerning the jdeps-related changes, as mentioned, I'm hesitant to move away from shared actions unless there is at least one example where they don't work as they should .

I'll have to reproduce this later. Busy week finishing off.

Which problem does this commit solves? Why should we prefer the project view from .bazelbsp? IMHO all .bazelproject paths except for repo root are some legacy artefacts and shouldn't be considered in future

I'm trying to programmatically choose to import a specific foo.bazelproject in my monorepo. The way the plugin works by default at least in my testing is that it it always selects the root .bazelproject. The .bazelbsp/.bazelproject that I populate just has an import statement to load the foo.bazelproject file

[tboernerapex]

PR: Fix project view file selection and related issues

Context

When a Bazel project is reopened in IntelliJ, the IDE shows an "unlinked project" balloon. Clicking it triggers BazelUnlinkedProjectAware.linkAndLoadProjectAsync, which finds a workspace file (e.g. MODULE.bazel) and calls closeAndReopenAsBazelProject. This reopens the project through BazelProjectOpenProcessor.

Because the workspace file matches WORKSPACE_FILE_NAMES, getProjectViewPath returns null (see utils.kt:58). That means beforeOpen in BazelProjectOpenProcessor never sets bazelProjectSettings.projectViewPath. The project opens with no persisted project view path, and RegenerateProjectViewFileContentPreSyncHook must select one from scratch via ProjectViewFileUtils.calculateProjectViewFilePath(overwrite=false).

This is the context for the first two fixes below.

---

Fix 1: Prefer .bazelbsp/.bazelproject over root-level project view files

Commit: 31b99ec — fix bazel: prefer .bazelbsp/.bazelproject over persisted root-level project view path

Problem

ProjectViewFileUtils.calculateProjectViewFilePath had this priority chain when overwrite=false:

1. Explicit argument (projectViewPath)
2. System property (PROJECT_VIEW_FILE_SYSTEM_PROPERTY)
3. Legacy root-level .bazelproject files (calculateLegacyManagedProjectViewFile)
4. Fallback: create .bazelbsp/.bazelproject

If a root-level .bazelproject file existed alongside an existing .bazelbsp/.bazelproject, the legacy file was selected at step 3 — even if .bazelbsp/.bazelproject already contained the correct project view configuration (e.g. with import directives pointing to a team-managed project view file).

Additionally, RegenerateProjectViewFileContentPreSyncHook had an early-return path: if the persisted projectViewPath pointed to any valid file, it called forceReparseCurrentProjectViewFiles() and returned without ever checking whether .bazelbsp/.bazelproject existed and should be preferred.

Fix

ProjectViewFileUtils.kt: Insert a new calculateExistingBazelbspProjectViewFile step in the priority chain, between the system property and the legacy root-level scan. When an existing .bazelbsp/.bazelproject is found, it takes priority over root-level files, and the legacy scan is skipped entirely.

RegenerateProjectViewFileContentPreSyncHook.kt: In the early-return path (persisted path is a valid file), check whether .bazelbsp/.bazelproject also exists. If it does and differs from the persisted path, override the persisted path to .bazelbsp/.bazelproject.

---

Fix 2: Pre-refresh imported .bazelproject files into VFS before parsing

Commit: 1300131 — fix bazel: pre-refresh imported .bazelproject files into VFS before parsing

Problem

.bazelbsp/.bazelproject commonly contains import or try_import directives pointing to other .bazelproject files. During parsing, ProjectView.tryResolveImportFile resolves these via project.rootDir.resolveFromRootOrRelative(pathString), which only searches IntelliJ's in-memory VFS cache.

On first open of a large monorepo, the imported file may exist on disk but not yet be present in the VFS cache. When this happens:

• import directives throw an error
• try_import directives silently return null, causing the import to be skipped and the sync to fall back to indexing the entire workspace

Fix

DefaultProjectViewService.kt: Add a preRefreshImports step that runs before the readAction block in parseProjectViewAsync. It reads the raw file content (bypassing VFS/PSI), extracts import/try_import paths with a regex, and calls refreshAndFindVirtualFile() on each to force-load them into the VFS cache before the PSI parser encounters them.

---

Fix 3: Add missing BUILD file for intellij.bazel.python.backend

Commit: 9a8487e — fix(bazel): add missing BUILD file for intellij.bazel.python.backend

Problem

The intellij.bazel.python.backend module was added in commit 12e66e0 but its Bazel BUILD file and the corresponding srcs entry in the root BUILD file were missing. This caused the plugin zip to omit the python backend jar. IntelliJ then failed to load the plugin with: "Cannot resolve intellij.bazel.python.backend.xml".

Fix

Add python/backend/BUILD and include it in the root BUILD file's srcs.

---

Fix 4: Fix ProjectView bundle exceptions

Commit: 97d9226 — BAZEL-3058 bazel: fix ProjectView bundle exceptions

Problem

The project view message bundle was split across two locations: ProjectViewBundle.properties in intellij.bazel.core and BazelProjectViewBundle.properties in intellij.bazel.projectview. Some classes referenced the wrong bundle, and the core bundle file was not registered in the plugin XML. This caused runtime MissingResourceException errors when project view UI strings were accessed.

Fix

Remove the duplicate ProjectViewBundle.properties from intellij.bazel.core. Merge all message keys into BazelProjectViewBundle.properties in intellij.bazel.projectview. Delete the now-unused BazelProjectViewBundle.kt wrapper class. Update ProjectViewBundle.kt and all referencing classes (ProjectViewFileType, ProjectViewLanguageCodeStyleSettingsProvider, ProjectViewParser) to use the consolidated bundle. Register the bundle in intellij.bazel.projectview.xml.

[tboernerapex]

Evgenii Pasynkov (@noxvost) Klaus Aehlig (@aehlig) let me know if you need anything else.

[Evgenii Pasynkov (noxvost)]

Hi tboernerapex, sorry for long time to answer.
We are not ready to merge your suggestions into out codebase right now.
First of all, we are deeply refactoring the whole project open workflow at the moment, so the .bazelproject becomes THE project, and to open another project view one have to close one project and open another. Seems that it will make more sense with your intention - just open any .bazelproject you'd like. We will merge our refactoing in a couple of days