Project Views (.bazelproject files)
The project view file (.bazelproject) is used to import a subset of Bazel packages into the IDE. The project view determines which rules are imported and how.
The project view file uses a python-like format with 2 spaces indentation and # comments. You can share the .bazelproject file between projects, use your own copy, or both.
In general, you can start with just
targets and add
more sections as you want to further tweak your IDE workspace.
Creating the Project View
The easiest way is to import an existing
.bazelproject file. If you already have a different project open in the IDE,
this action is available from
File > Import Bazel Project.
To modify an existing project, use
Bazel > Open Project View Files. Note,
you can still use an import of a shared .bazelproject, and then include
additional directories and targets below.
A list of directories that will be added as source. Each directory entry must point to a workspace directory. All files under directories are included in the import. Directories are always recursive.
If you want to exclude directories, prefix the entry with a minus ("-") sign.
Note: Including a directory only imports the files. If you want to resolve your source, it must be reachable via a target (see below).
directories: java/com/google/android/myproject javatests/com/google/android/myproject -javatests/com/google/android/myproject/not_this
To resolve source files under an imported directory, the source must be
reachable from one of your targets. These are full bazel target expressions, and
The more targets you have, the slower your Bazel sync will be. You can use
negative targets to have bazel ignore certain targets
-//java/com/google/foo:MyExpensiveTarget). See also
targets: //java/com/google/android/myproject:MyProjectDevTarget //javatests/com/google/android/myproject/...
Imports another project view.
You may use multiple imports in any project view. Any list type sections
directories) compose. Single-value sections (eg.
override and use the last one encountered, depth-first parse order
(i.e. imports are evaluated as they are encountered).
Use this to specify the kind of languages you want to support in the project. This setting controls certain global project structure settings like the kind of SDK we configure (eg. "java" gets a normal Java SDK, but "android" will get an Android SDK).
If omitted, we use the default workspace type for your IDE.
This setting is usually only necessary if you want to use Android Studio for a Java-only project (eg.)
- Android Studio: android, java
By default, we import the language classes implied by your workspace type. If you want additional languages in your workspace, you can use this attribute.
- Android Studio: android, java
additional_languages: dart typescript
Use this to override the language level used by the IDE. Normally this
is inferred from the corresponding
java_toolchain rule reachable
from your targets.
A list of workspace-relative glob patterns. Determines which sources IntelliJ treats as test sources. This is mostly visual (IntelliJ marks these in green).
NOTE: Deprecated. You should never need to use this project view directive.
Forces a import of a particular rule's outputs. This is useful if you have rule under your source directories that you want to import as jars instead of sources.
You should normally not have to use this. If you do, it maybe be you are mixing generated and non-generated sources in the same rule. Consider splitting up the rule instead of using this attribute.
NOTE: Deprecated. Prefer the
Drops a target completely, ignoring its sources and outputs. The target will still be built and the IDE is still aware that a rule of this name exists.
A set of workspace-relative glob patterns that match jars. Can be used to resolve classpath conflicts where the one version policy is violated. You should normally not have to use this.
NOTE: You can exclude a library by right-clicking on it in the project tree and choosing "Exclude Library".
NOTE: This attribute matches jars in the output tree, not rules.
A set of bazel flags that get passed to all bazel command invocations as arguments (eg. to bazel build, test, run, etc).
build_flags: --android_sdk=//third_party/java/android/android_sdk_linux:android_sdk_tools --config=android
A list of XML files which will be imported as run configurations during bazel sync. By default these run configurations will be updated during sync to match any changes to the XML.
Bazel run configurations can be exported to XML using the
Bazel > Export Run
Configurations action. See the full workflow for
import_run_configurations: java/com/google/android/myproject/run_project.xml java/com/google/android/myproject/test_project.xml
Android Studio only
Selects which android platform from your SDK directory to use. Corresponds to a subdirectory in ~/<sdk>/platforms.
Required if your
workspace_type is "android". Note
that this is implicit if you're using ASwB.
Points to a rule that you want to
bazel run during sync
to get typescript support.
Required if you have requested typescript support in your
.bazelproject files can be checked into source control. By convention, they live next to the BUILD file people import.
If your project has multiple different views, you may check in multiple files with the .bazelproject extension into the same directory. The user can choose to import any one of these.