Repository Language Configuration + Java Support

[holtherndon-stripe]

Description

As part of getting Java specific features (Java Indexing) working at Stripe, we needed to remove the need for hardcoded repository names used internally at Uber. To allow for this to be 'company agnostic' I added a languages section to the entity.MonorepoConfigEntry that allows each repo to have a set of languages that are enabled for it. (Currently only adding java to the list changes anything.)

As part of this, the way repositories at Stripe are structured, we have /src/ twice in our paths due to repository locations on disk. To allow this to work in a generic fashion, GetJavaTarget now operates by looking at the directory tree for BUILD(.bazel)? files to return the appropriate target directory based on the nearest parent Bazel build file.

To allow for tests using GetJavaTarget to operate on the filesystem rather than delimiters in strings, the tests needed to be wired up for providing the fs.UlspFS to allow for mocked file systems.

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change specifically breaks the lm/fievel repository. It will need to have the following Yaml configuration changes in base.yaml to enable Java language support

      languages:
        - java

• Documentation update
• Refactoring (no functional changes)
• Performance improvement
• Test improvement

Component(s) Affected

• Language Server (ULSP)
• SCIP Generation (Python utilities)
• VS Code/Cursor Extension
• Java Aggregator
• Build System (Bazel)
• Documentation
• Tests

Testing

• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes (bazel test //...)
  • //... is broken on my machine, but bazel test //src/ulsp/... was used.
• I have tested this manually with a real project
  • Tested on our internal Java monorepo.

Manual Testing Details

Describe how you tested these changes:

• IDE used for testing: VScode
• Project(s) tested against: Stripe Internal Repository
• Specific features/scenarios verified: CodeLenses / Scip Sync

Checklist

• My code follows the existing code style and conventions
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have updated BUILD.bazel files if I added new source files
• My changes generate no new warnings
• Any dependent changes have been merged and published

Screenshots/Logs (if applicable)

These are screenshots from usages in our internal Java Monorepo. Certain pieces redacted for security purposes.

CodeLenses in file:

Clicking Sync File CodeLense:

(I haven't run a full sync yet - @murray-stripe has that in his branch, but this changeset does not change that flow)

Clicking Build CodeLense:

Related Issues

Fixes #(issue number)
Closes #(issue number)
Related to #(issue number)

Additional Notes

• Reviewer note: 📚 This PR is structured to be reviewed commit-by-commit if you prefer
• This does change the assumption of the GetJavaTarget method - depending on where the buildfiles are located internally at Uber, it might diverge. Let me know if it's not what it's intended purpose is and we can adjust.
• This also doesn't appear to (or is intended) fix the test explorer, that looks to be elsewhere and still tied to some internal Uber assumptions.
  

[CLAassistant]

All committers have signed the CLA.

[holtherndon-stripe]

@JamyDev - Addressed comments, and removed the monorepo names from source entirely! (And added explicit test for bazel-out)