This is needed to enable automatic layout and to allow merging two JSON plugins to a single one. Also, this is needed to allow adding dependency on JSON from the unified YAML plugin.
'intellij.json' is registered as an embedded content module, so it uses the main plugin classloader, and now has a dependency on 'intellij.json.split' module. This ensures that classes from both modules are available to content modules from other plugins which declare dependency on JSON plugin as before.
After this change, build scripts don't put intellij.toml.json to a separate JAR anymore, and an explicit adjustment is needed in the Wiremock plugin's layout to avoid creating an unnecessary separate JAR.
GitOrigin-RevId: be77513b7f0c1e397b4f6dda7524aa6978fa2a90
If we could specify custom path for required content modules, we could include json.split into the monolith intellij.json plugin as well.
Currently we have to keep it in a separate jar to satisfy the test. It seems to make litle sense since no other plugin in monolith ide depends on json.split.
GitOrigin-RevId: 77362ce4de0957d941844003d69593c273269a68
- it allows to avoid duplicated registrations in different plugin descriptors
- it loads json.split module's classes with a main plugin classloader -> classes from the json.split module can be directly accessed from the main plugin module
GitOrigin-RevId: 052de488d023b25dd9362a62ae45232d292ded13
- JSON becomes a true plugin instead of a bundled module.
- New plugin's ID is intentionally set equal to the old module name so that external dependent plugins would not face difficulties migrating to the new layout.
- All discovered internal plugins that implicitly depended on the JSON module currently unconditionally depend on the plugin.
- Consider extracting optional modules in a subset of affected plugins: spring.boot, intellij.yaml, intellij.java
- Consider testing the following IDEs that bundle JSON extension using xml:include: writerside, rider
- Refactor PlatformLangXmlPlugin to avoid api breakages
GitOrigin-RevId: 7d92b0c5905154c4f6f25d55f3246e79da79e278
Unspecified type in the meta schema lead to treating many of the instance fields as either an object, or a boolean (as it is specified in the #meta schema node).
GitOrigin-RevId: 4c1441f161039eef502fd7e3e4b64295d04cffc3
this is needed to handle cases when the value is "expandable" - there are two different options to write the same (product = lib or product {type = lib}), but in some cases one of them requires expanding by default (lib requires a set of platforms)
instead of introducing the notion of "expandable" into the schema, we just provide an ability to provide a custom completion insert handler to handle tricky cases like that
GitOrigin-RevId: 5e54f19326891d7d02061b338efb392fc0ae2634
- Use virtual file as a key in schema storage map
- Prefer KFMap instead of lazy properties
- Fix various minor code-style problems
GitOrigin-RevId: 20825456c5b98f654e3957eb9783badb21a6d433
Current commit disables the new JsonSchemaObject implementation to record test results before the recent susystem changes. After the statistics is collected, new implementation should be turned on again for further comparison
GitOrigin-RevId: f9cc59d2f4df2f47c6f62bf77cf3ff2efbe073fe
The key is used across the json plugin codebase in the hottest in terms of memory allocations places. The goal is to create such a schema object implementation, that would be capable of providing schema data the same way that the existing API does, but to save up on memory allocations and GC.
GitOrigin-RevId: e763ff89ec81628dd58708d6b18118939fc8b4c7
