You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are supporting Project View files, which provide hints and metadata for how IDEs should import slices of Bazel workspaces. We will continue to support them, but...
I prefer an inline approach. I think we should support (and encourage) inline annotations in comments in the BUILD file. This initial story will choose just one use case, and then we build from there. The examples below are just ideas for how this feature could be used.
This will be useful when there are multiple packages named apple-api imported in the workspace. By default BEF will name the first it finds 'apple-api', and the second 'apple-api2'. By using the annotation, better names will be used for the projects during import. See Issue #40 where this solution would be used.
BEF currently reads .bazelrc data to configure the JDK for all projects imported from the workspace. The user can then override it for each project, manually. It is the JDK used by JDT to do code completion and inline compilation. But it would be nicer if this was configured by annotation, then all users would get it automatically. This could be read out of the rules (javacopt) but if there are conflicts within the package it is better for an annotation to tell us what to do.
In this example, this Bazel package is a component used by three teams: orion, fusion, and troika teams within ACME Inc.
(every big company has had a big project code-named 'fusion' at some point). These working sets would be the equivalent for the Project View 'directories' concept. The user would choose one or more workingsets during import, and all packages annotated with those labels would be imported. Then, using Eclipse Working Sets, the user could toggle which projects were active in the view.
The text was updated successfully, but these errors were encountered:
We are supporting Project View files, which provide hints and metadata for how IDEs should import slices of Bazel workspaces. We will continue to support them, but...
I prefer an inline approach. I think we should support (and encourage) inline annotations in comments in the BUILD file. This initial story will choose just one use case, and then we build from there. The examples below are just ideas for how this feature could be used.
Some ideas:
# @projectname salad-apple-api
This will be useful when there are multiple packages named apple-api imported in the workspace. By default BEF will name the first it finds 'apple-api', and the second 'apple-api2'. By using the annotation, better names will be used for the projects during import. See Issue #40 where this solution would be used.
# @jdk11
BEF currently reads .bazelrc data to configure the JDK for all projects imported from the workspace. The user can then override it for each project, manually. It is the JDK used by JDT to do code completion and inline compilation. But it would be nicer if this was configured by annotation, then all users would get it automatically. This could be read out of the rules (javacopt) but if there are conflicts within the package it is better for an annotation to tell us what to do.
# @workingset orion
# @workingset fusion
# @workingset troika
In this example, this Bazel package is a component used by three teams: orion, fusion, and troika teams within ACME Inc.
(every big company has had a big project code-named 'fusion' at some point). These working sets would be the equivalent for the Project View 'directories' concept. The user would choose one or more workingsets during import, and all packages annotated with those labels would be imported. Then, using Eclipse Working Sets, the user could toggle which projects were active in the view.
The text was updated successfully, but these errors were encountered: