Add configuration options for update checks and custom component paths

[himicoswilson]

New Configuration Options:

• check_updates: Controls when to check for updates for JDTLS, Lombok, and Java Debug components

  • "always" (default): Always check for and download the latest version on every startup
  • "once": Check for updates only if no local installation exists
  • "never": Never check for updates, only use existing local installations (will error if missing)
  • Note: Invalid values default to "always"

• jdtls_launcher: Path to a custom JDTLS launcher script

  • When set, the extension uses your provided launcher instead of the managed installation
  • Overrides automatic downloads; check_updates is ignored for JDTLS

• lombok_jar: Path to a custom Lombok JAR file

  • When set, the extension uses your provided JAR instead of downloading it
  • Overrides automatic downloads; check_updates is ignored for Lombok

• java_debug_jar: Path to a custom Java Debug plugin JAR file

  • When set, the extension uses your provided debugger instead of downloading it
  • Overrides automatic downloads; check_updates is ignored for the debugger

Behavior:

• User-provided custom paths always take precedence over managed installations
• When a custom path is specified for a component, update checks are skipped for that component only
• All paths support home directory expansion (e.g., ~/path/to/jar)

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @himicoswilson on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[himicoswilson]

We require contributors to sign our Contributor License Agreement, and we don't have @himicoswilson on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

@cla-bot check

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[playdohface]

A few points here:

• I am not sure the semantics of check_updates_on_startup are ideal. It should probably have options once | never | always, where once means do the download if you have nothing but don't update the versions.
• Whatever semantics and names we agree on, they should be documented in the README
• Some of the comments are just stating the obvious and not helpful, i'd rather read the code

[tartarughina]

As discussed in #125, this approach of allowing users to specify the version they want to download makes the code more complex and, in my opinion, difficult to maintain.

I would prefer the option to provide a file path instead of downloading something for the user.

The idea about updates could be improved, as suggested by @playdohface. The current implementation for downloading components requires an overall first step before adopting such a feature. Currently, things are scattered. We would likely have a single component that, when the extension starts, checks for updates and manages downloads.

[himicoswilson]

@playdohface I agree with your idea about check_updates_on_startup.
The once | never | always options make the behavior much clearer and more flexible.

My initial reason for designing this feature was the network environment in China — sometimes checking for updates can hang for a long time and block normal startup.
That’s why I modified the source code to make the update behavior more controllable.

Let’s go with your proposed approach, and we can document it properly in the README.

[himicoswilson]

@tartarughina
I agree with the idea of providing a file path option instead of download URLs.
The update mechanism improvement is already on the roadmap.

[himicoswilson]

@tartarughina Due to the sandbox mechanism, I don't think it's necessary to provide a file path.

[playdohface]

If we don't let the user supply the file-paths, how will they know where to put the files if they want to manage them manually?

[himicoswilson]

@playdohface Thanks for the careful review!
That’s why I removed that feature. The system now handles file locations instead of users needing to manage paths.

[tartarughina]

I like the general approach and idea brought forward by this PR although I think we are missing an opportunity of having a single component that handles updates, downloads and eventually manages user provide paths.

For this reason, before going blindly into new revisions, let's come up with a proper design. We have #125 which is a good place where to continue the conversation. I'm not asking for anything fancy and corporate level, a sketch on Excalidraw is perfectly fine.

[playdohface]

I think generally this looks fine now, I left some nitpicks. I haven't had the time to test the behaviour yet I'll do that later today and if it works I think we can land this and then work on letting users supply the file paths in a different PR