Optimize project structure for cases without Java files

[runchen0919]

Fixed: #39

@guw

[github-actions]

Test Results

 42 files  ±0   42 suites  ±0   1d 7h 36m 33s ⏱️ + 3h 50m 56s
 67 tests ±0   66 ✅ ±0   1 💤 ±0  0 ❌ ±0 
134 runs  ±0  123 ✅ ±0  11 💤 ±0  0 ❌ ±0 

Results for commit d8790ee. ± Comparison against base commit 9542833.

♻️ This comment has been updated with latest results.

[runchen0919]

@guw I updated the PR, and my test environment configuration is as follows:

001/.bazelversion

7.4.1

001/.eclipse/.bazelproject

# The project view file (.bazelproject) is used to import targets into the IDE.
#
# See: https://ij.bazel.build/docs/project-views.html
#
# This files provides a default experience for developers working with the project.
# You should customize it to suite your needs.

directories:
  # .  # import everything (remove the dot if this is too much)
  module4/java/com/project/server/examples

derive_targets_from_directories: true

target_discovery_settings:
  buildfile_query=//module4/...

[guw]

Why does no java file exists? Is it generated by some other target and copied into the source tree?

[runchen0919]

The project structure was maintained in this way; it wasn't generated. Specifically, there are no other Java files in the same directory as BUILD in the source code.

[guw]

Let's figure out a way without temp. files then. I think the logic should be fixed to handle this case, i.e. .java sources within nested directories.

[runchen0919]

This method ensures that at least one Java file in the same directory as the BUILD file can be detected in the event of multiple nested levels. If not, temporary Java files are created and then deleted after use.

[guw]

Right but it does not belong here.

The logic to detect source directories is here:

bazel-eclipse/bundles/com.salesforce.bazel.eclipse.core/src/com/salesforce/bazel/eclipse/core/model/discovery/projects/JavaSourceInfo.java

Line 114 in 9542833

public void analyzeSourceDirectories(MultiStatus result,

It looks like it's missing to identify that particular setup.

[runchen0919]

I noticed the logic here. However, it's quite lengthy. I wanted to directly reuse the logic of detectPackagePath, so I used the temporary file creation approach. If I didn't create a temporary file, should I add more code to handle this case in the analyzeSourceDirectories method? Or do you think refactoring this method would be a reasonable thing to do?

[guw]

It's all the weirdness trying to map from Bazel srcs to Java source directories required by JDT.
The problem is that bazel query does not return directories but only list of files. Thus, we try to identify the directory. Depending on the provisioning strategy this could be more or less challenging.

The method is quite lengthy and increasingly challenging to maintain at this point. I have not had time to investigate a different implementation, which could also be better unit tested. I am not going to stop you from refactoring it perhaps into a separate heuristics object. I can support you with providing requirements. Although I will probably forget a few edge cases, which I need to look up from Git commit history.

[guw]

I think the next step is to add some assertions to

bazel-eclipse/tests/com.salesforce.bazel.eclipse.core.tests/src/com/salesforce/bazel/eclipse/core/tests/it/Workspace001Test_Provisioning.java

Line 42 in 9542833

public class Workspace001Test_Provisioning {

[runchen0919]

cc: @guw The creation of temporary files has been removed, and the method now scans the file structure to infer the package name.