LCLS does not yet invalidate custom config files

[dshimo]

As a follow up to #66, the set of custom config files, specifically .properties and .env files, will only grow as no behavior for invalidation has been written. As a consequence, if the liberty-plugin-config.xml gets deleted or changed to remove a reference, that file would continue to receive LCLS support.

The logic for adding to the custom config file starts in LibertyWorkspaceService.didChangedWatchFiles, which adds to the set regardless of creation, change, or deletion.

[scottkurz]

For a case like this I wonder how bad it is to continue to offer LCLS assist ?

I was considering opening an issue suggesting we also add assist to any file named 'bootstrap.properties' or 'server.env' no matter what the location or what the plugin config XML points to.

Though that's probably best treated as a separate issue, maybe we could start w/ one discussion in our next DXDI call.

Maybe I could sum it up as saying consider erring on the side of adding assistance.

[scottkurz]

DXDI 2023-10-25 UPDATE:

• Agreed generally it was OK to provide assist even when the file in question was not currently configured as the active config file (according to plugin-cfg xml).
• Noted that initially, after a git clone, before any build, this file would not even be generated.. so we could detect this as "not the active config file" even though it will be once the initial build is done.
• Noted that while the idea has been raised to do some kind of Maven build upon import which would generate the plugin cfg, we still have not gotten to the point of doing this yet (and it'd be non-trivial and IDE specific).
• Noted the analogous case for XML: we will provide assist for any XML with <server> as root, so we could likewise be more liberal in assistance here too.
• Noted ENHANCEMENT idea if someone wants to follow-up: Have an enhancement that provides some kind of warning or view that the file in question is vs. isn't the active config file.

Decided:

1. No need to "invalidate" assist for previous config files: bootstrap.properties, server.env - If they were once config files, not valuable to remove this support
2. Also worth providing assist for any file named bootstrap.properties or server.env

@evie-lau will let you to decide what issues/PR to use for this.

[evie-lau]

I summarized the discussion takes in a new issue, and resolved the rest of the points, including code comments regarding this issue of invalidating config files.