VSCode cross project additional-spring-configuration-metadata.json

[jcrben]

Expected Behavior
I have a variety of additional properties which are based upon deployment or libraries. I want my editor to be informed of these but I don't want to embed these configurations into every single project which imports these.

I'd like to have a setting where I can point to a common additional-spring-configuration-metadata.json in some path somewhere.

Current Behavior

The quick fix creates a META-INF folder which has additional-spring-configuration-metadata.json in it. That's local clutter in the project. It also didn't work for me for some reason but in any case but doesn't matter too much as I wouldn't commit it.

Context
I just went ahead and added "spring-boot.ls.problem.application-properties.PROP_UNKNOWN_PROPERTY": "IGNORE" to my preferences for now.

Saw related issues like #332

[martinlippert]

Thanks @jcrben for reporting this, makes a lot of sense to me. I think we should add the option to store the information in a additional-spring-configuration-metadata.json file that is stored in the workspace metadata (or somewhere else outside of the projects themselves) - and probably a preference to control the exact location of this file.

[BoykoAlex]

I think we'd want to track changes to this file. If yes, and if the file is outside workspace somewhere for vscode or outside projects in Eclipse then we won't be receiving LSP file change notification messages. Perhaps we could employ Watch Service API or VFS from Apache Commons but it smells overkill to me...

We may not listen to file changes of course... I just thought it'd be nice to provide a quick fix that adds new property metadata to this file. Once metadata JSON is added the default data is more of a stab for real data that user fills out and then saves. These are the file modification events we'd like to react on in this case...

As an alternative we could host properties metadata JSON as a value under a key in the settings. This will make modifications tracking easy. Or perhaps require users to place this file under the workspace resources somewhere such that changes handled by the LSP...

[martinlippert]

Good points @BoykoAlex, let's evaluate those a bit. I am thinking along these lines:

• usually, a library like Spring Boot (or any library that contains configuration properties should include the corresponding processor in the build, so that the library provides the spring-configuration-metadata.json out-of-the-box. This is the most common way, I think.
• the next part is about your own projects, where you can include the configuration processor step in the build definition as well, so that the metadata JSON is automatically created for your own configuration properties as well (and taken into account by the tooling)

Beyond those two use cases, the tooling supports an additional-spring-configuration-metadata.json file that you can edit manually and put that into your projects (as mentioned in the description of this issue). The quick fix is just a convenient way to create this file (or to add a specific property to it), but it should be a rare and exceptional case.

For this rare case, I would be fine with a file outside of the project and the workspace, which location you can define in a setting, and that the tooling does NOT watch for changes. We could add an action to trigger the "re-indexing" of the available metadata altogether which the user could trigger when the file got edited/changed.

In case the setting for this external additional file is set, the quick fix could show up to add an entry to that file - much in the same way than the quick fix would add an entry for an existing additional-spring-configuration-metadata.json file.

WDYT?

[martinlippert]

As an alternative we could host properties metadata JSON as a value under a key in the settings. This will make modifications tracking easy. Or perhaps require users to place this file under the workspace resources somewhere such that changes handled by the LSP...

I like that part as well. If combined with a quick fix to add an item for a missing property (for example) would have the benefit of listening to changes is easy and the user could decide on their own whether to have this as a project/workspace-specific setting (and therefore commit those preferences as part of the project), a user-specific setting, or a IDE-installation-specific setting. Sounds like an easier solution with a lot of benefits when compared to a custom additional file.

@jcrben Would that work for your case as well? Then, I would prefer this.

[jcrben]

@martinlippert Are you talking about switching away from your comment "For this rare case, I would be fine with a file outside of the project and the workspace, which location you can define in a setting, and that the tooling does NOT watch for changes"?

The thing I really care about it scalability - a way to share these among thousands of projects without having to duplicate them inside every project.

I don't want to force engineers to use a specific IDE - VSCode is actually much less common for Java at my company than Intellij or Eclipse - so using a VSCode specific setting isn't ideal. Ideally we can have a common file which can be leveraged for various different IDEs, even if the intellisense isn't quite available for all the IDEs.

But if you need to put it into an IDE-specific setting because the file introduces complexity of some sort, that's OK too. Anything is better than nothing. I can live with copying these into both the shared Eclipse settings and VSCode separately I suppose. :)

Language sensing of new properties being added to the file isn't important for me at the project level because settings can be controlled at the enterprise level and processes can be put into place for using new settings which include editing the file. Since adding properties is more of an involved process for enterprise-level properties, people can restart to get the new intellisense or use an action as you said.

As a sidenote, long-run, supporting new properties at both the shared enterprise and the project level would be nice, but for now shared enterprise properties is what really matters for me.