Import Java Tutorial

[snjeza]

@guw @lonhutt I haven't be able to create an issue on https://github.com/eclipseguru/bazel-eclipse/. Because of that I have created it here.

I have tried to import java-tutorial into Eclipse and VS Code.
jjava-tutorial has been created based on https://bazel.build/start/java.
I have found the following issues:

1. Bazel Eclipse creates several error markers as

a) Folder '/home/snjeza/bazel-examples/java-tutorial/src/main/java/com/example' contains more Java files then configured in Bazel. This is a scenario which is challenging to support in IDEs! Consider re-structuring your source code into separate folder hierarchies and Bazel packages.

• src/main/java/com/example/ProjectRunner.java

The related issue - #116

2. Bazel Eclipse creates projects named :greeter, :ProjectRunner, src.main.java.com.example.cmdline:runner
   Eclipse/JDT can't execute a main method on Linuxu and Mac if the classpath contains : (colon)

3. Bazel Eclipse creates duplicate links for all of the three source files in linked-srcs and linked-test-srcs
   The related issue - .java is not on the class path of project A, only syntax errors are reported #143

4. Bazel Eclipse copies BUILD*, MODEL*, WORKSPACE* to output folder.
   When importing java-tutorial, Bazel Eclipse copies /src/main/java/com/example/cmdline/BUILD to./.eclipse/projects/src.main.java.com.example.cmdline_runner/eclipse-bin/com/example/cmdline/
   If the "View>Command Palette>Java: Clean Java Language Server workspace" command is called in VS Code, java-tutorial won't be imported correctly.
   BazelProjectImporter creates the .eclipse/projects/.eclipse.projects.src.main.java.com.example.cmdline_runner.eclipse-bin.com.example.cmdline_runner project based on the /.eclipse/projects/src.main.java.com.example.cmdline_runner/eclipse-bin/com/example/cmdline/BUILD file

I have created a PR that fixes these issues in the following way:

1. replaces error markers with warning markers
2. if a project name contains : (colon), the PR replaces it with _ (underscore)
3. fixes BaseProvisioningStrategy.java
4. adds excluding="**/BUILD*|**/MODULE*|**/WORKSPACE*" to source classpath containers

After applying eclipseguru/bazel-eclipse#1, java-tutorial will be able to be imported; Runner and ProjectRunner will be able to be executed in Eclipse as well as in VS Code.

Test VSIX: https://drive.google.com/file/d/1xgOnnSZxmK6c4rzZYSdVS2O9uC5FnHar/view?usp=sharing

[guw]

@snjeza I enabled issues in the other repository because this one is archived now.

I think the java-example works better with the project-per-package. I think it might be about time to have some heuristics during import to recommend this strategy over the default project-per-target. It makes things more natural to Eclipse users specifically.

I would like to keep the severity as error for now because this setup is really challenging to get right. I am working with lots of virtual folders and links to shoehorn the Bazel world into the limited Eclipse JDT project/classpath/resource world.

Note, the : colon can be configured with project_name_separator_char setting. The colon as default was chosen because of similarity to Bazel labels, i.e. it separates a target name from the package path. Should we switch the default? Is it causing issues for you? Keep in mind we don't really support Windows. Bazel on Windows is something to avoid.

[tsmaeder]

@guw IMO, in bazel-vscode, we should not care about how the project structure would look in the Eclipse UI. In the end, we just want the compiler to see the correct name environment.

[snjeza]

I think the java-example works better with the project-per-package. I think it might be about time to have some heuristics during import to recommend this strategy over the default project-per-target. It makes things more natural to Eclipse users specifically.

@guw I have tried to import java-tutorial using the project-per-package strategy. Bazel Feature can't find a package of :greeter and :ProjectRunner. See https://github.com/snjeza/java-tutorial/blob/main/BUILD

The project-per-package strategy doesn't accept the BUILD file defined in the root of a project.

Note, the : colon can be configured with project_name_separator_char setting. The colon as default was chosen because of similarity to Bazel labels, i.e. it separates a target name from the package path. Should we switch the default? Is it causing issues for you?

If you apply the PR, the default on Linux and Mac will be _ (underscore).

Keep in mind we don't really support Windows. Bazel on Windows is something to avoid.

The issue with : (colon) can't be reproduced on Windows because ; (semicolon) is the default path separator on Windows.

I would like to keep the severity as error for now because this setup is really challenging to get right. I am working with lots of virtual folders and links to shoehorn the Bazel world into the limited Eclipse JDT project/classpath/resource world.

We could add a new property - com.salesforce.bazel.recommendations=error|warning|ignore, for example .
In my opinion, importing Bazel java tutorial would need to work without any changes.

[guw]

IMO, in bazel-vscode, we should not care about how the project structure would look in the Eclipse UI. In the end, we just want the compiler to see the correct name environment.

Yes, I thought about a custom name environment too. That would probably be the best. Ideally one that does not need IResource. However, the way JDT works today (unfortunately) is that I need to setup a new dummy IJavaProject just to give an IPackageFragmentRoot a specific classpath. All IPackageFragmentRoot share the same classpath otherwise, which clashes with Bazel where each target has a unique classpath.

Thus, project-per-target sets up a lot of fake projects with linked folders and exclusion to try to be correct. But this is a very poor experience in JDT. It doesn't really matter whether it's Eclipse IDE or JDT-LS. It's easier to debug in Eclipse IDE, though. :)

If you apply the PR, the default on Linux and Mac will be _ (underscore).

@snjeza You have not explained the issue. I was assuming it's a Windows issue because of the : as drive name separator in paths.

Is it just cosmetic? If it's cosmetic it should be configurable. The _ can cause clashes and cannot be default (eg., //lib/foo:bar and //lib:foo_bar, separate things in Bazel and must result in separate projects).

In my opinion, importing Bazel java tutorial would need to work without any changes.

100% agree on this one. Ideally there would be no errors. But switching them to warnings seems wrong. Perhaps the algorithm for detecting this case needs adjustments so it's not reported anymore because the case is ok to support?

[guw]

BTW, any way to connect via https://slack.bazel.build/ and/or setup a call?

[tsmaeder]

@guw silly question: but which extension from the marketplace are we talking about? I can't for the life of me reproduce this issue: project-per-target seems to have no effect.

[guw]

sfdc.bazel-vscode-java (latest preview version). But I think the org is going to change. They lost access to it (see #158)

[snjeza]

You have not explained the issue. I was assuming it's a Windows issue because of the : as drive name separator in paths.
Is it just cosmetic? If it's cosmetic it should be configurable.

@guw The issue is related to a path separator that is a colon (:) on Linux and Mac and a semicolon (;) on Windows.
You can try to create a project named :test on Linux or Mac, create a class with the main method and try to run it..

The _ can cause clashes and cannot be default (eg., //lib/foo:bar and //lib:foo_bar, separate things in Bazel and must result in separate projects).

Can we use - (minus)?

100% agree on this one. Ideally there would be no errors. But switching them to warnings seems wrong. Perhaps the algorithm for detecting this case needs adjustments so it's not reported anymore because the case is ok to support?

I will try to solve it. java_tutorial contains three java files where each of them is declared in its target. In this case, we wouldn't need to create either an error or a warning.

but which extension from the marketplace are we talking about? I can't for the life of me reproduce this issue: project-per-target seems to have no effect.
sfdc.bazel-vscode-java (latest preview version). But I think the org is going to change. They lost access to it (see #158)

@tsmaeder sfdc.bazel-vscode-java is on Marketplace again.

[guw]

The issue is related to a path separator that is a colon (:) on Linux and Mac and a semicolon (;) on Windows.
You can try to create a project named :test on Linux or Mac, create a class with the main method and try to run it..

Is this a problem of wrong escaping used by launcher code? I can create files with : just fine on MacOS.

[snjeza]

Is this a problem of wrong escaping used by launcher code?

Yes it is. You should create a project named :test and try to run a class.

[guw]

@snjeza That's a bug for JDT or JDK then?

Update: It looks like they don't have support for escaping : colon. In that case we should change it.