You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
about the currently opened (MicroProfile or Quarkus) project and returns
53
+
the information to vscode-quarkus. The project information is then sent to
54
+
the MicroProfile language server
52
55
53
-
The information is computed by scanning all classes annotated with `@ConfigRoot` Quarkus annotation from all project classpath JARs and generating the proper Quarkus properties.
56
+
**Step 5.** vscode-quarkus receives the project information and sends it
57
+
to the MicroProfile language server.
54
58
55
-
For instance if the project has a `pom.xml` with this dependency:
59
+
**Step 6.** MicroProfile language server receives the information, adds it
60
+
to its cache, and returns the completion options stored in the
61
+
project information as the response to the `textDocument/completion`
62
+
request.
63
+
64
+
## Implementing language features for `application.properties`
65
+
When an `application.properties` file sends a request (e.g. textDocument/completion) to the
66
+
MicroProfile language server, the requests are accepted in
This class receives LSP requests for `application.properties` files.
69
+
70
+
Properties collected by the MicroProfile jdt.ls extension are cached to keep response times
71
+
fast.
72
+
Collecting properties will not be done unless absolutely necessary
73
+
(ie, if cache doesn't exist, if project dependencies change).
74
+
75
+
When the completion is triggered,
76
+
the MicroProfile LS checks the properties cache for the given `application.properties` file.
77
+
If the cache does not exist, it calls the `microprofile/projectInfo` request to call the JDT LS Extension [projectInfo delegate command handler ](https://github.com/redhat-developer/quarkus-ls/blob/0ff91b4d0fe4670584a3ad23fe645c8141df7f3d/microprofile.jdt/com.redhat.microprofile.jdt.core/src/main/java/com/redhat/microprofile/jdt/internal/core/ls/MicroProfileDelegateCommandHandler.java#L99) which
The scanner will collect the [io.quarkus.deployment.ApplicationConfig](https://github.com/quarkusio/quarkus/blob/master/core/deployment/src/main/java/io/quarkus/deployment/ApplicationConfig.java) class annotated with `@ConfigRoot` and will generate a Quarkus property for each field:
101
+
## Searching for properties in JARs not in the user's Quarkus project's classpath
102
+
Some Quarkus properties like `quarkus.hibernate-orm.dialect` are not defined in JARs belonging
103
+
to the current Quarkus project's classpath. Some Quarkus classpath JARs have deployment JARs.
104
+
Generally speaking, deployment JARs are not present in the project's classpath.
65
105
66
-
*`quarkus.application.name` for the `name` field.
67
-
*`quarkus.application.version` for the `version` field.
68
-
69
-
In addition, the Quarkus jdt.ls extension is able to manage `Quarkus deployment JAR`.
106
+
If classpath JARs have a deployment JAR, it will be defined in the
107
+
`META-INF/quarkus-extension.properties` file of the classpath JAR.
70
108
71
-
For instance if the project has a `pom.xml` with this dependency:
109
+
For example, the `quarkus-hibernate-orm-1.2.0.Final.jar` has a deployment JAR with
110
+
an artifactId of `quarkus-hibernate-orm-deployment`:
111
+
112
+
113
+
The MicroProfile jdt.ls extension creates a "fake" Java project with the deployment
114
+
JARs in its classpath and performs a scan for properties for this fake project, in order
115
+
to retreive the desired properties.
116
+
117
+
To make things more concrete:
118
+
119
+
Consider a Quarkus project with a `pom.xml` with this dependency:
72
120
73
121
```xml
74
122
<dependency>
@@ -77,14 +125,23 @@ For instance if the project has a `pom.xml` with this dependency:
77
125
</dependency>
78
126
```
79
127
80
-
this JAR doesn't contain the classes annotated with `@ConfigRoot`. The JAR which contains those classes is `quarkus-hibernate-orm-deployment*.jar`. This information comes from
81
-
the `META-INF/quarkus-extension.properties` of the `quarkus-hibernate-orm*.jar` as a property:
128
+
Properties like `quarkus.hibernate-orm.dialect` and `quarkus.hibernate-orm.sql-load-script` are
129
+
not defined (no classes annotated with `@ConfigRoot`) in the `quarkus-hibernate-orm*.jar` JAR.
130
+
131
+
Those properties are located in its deployment JAR: `quarkus-hibernate-orm-deployment*.jar`.
132
+
133
+
The deployment jar is listed in `META-INF/quarkus-extension.properties` from the `quarkus-hibernate-orm*.jar` as a property:
Under the hood, the quarkus jdt.ls extension delegates the resolution (i.e. download) of those deployment jars to Maven, regardless of the user project's build system. So, a project depending on:
139
+
Note that in most cases, a Quarkus project would not have deployment JARs listed as dependencies in the project's
140
+
`pom.xml`, which is why the deployment JARs would not be in the project's classpath.
141
+
142
+
Therefore in order to scan for the properties in the deployment JAR, under the hood, the MicroProfile jdt.ls extension delegates the resolution (i.e. download) of those deployment jars to Maven, regardless of the user project's build system.
143
+
144
+
In conclusion, a project depending on:
88
145
89
146
```xml
90
147
<dependency>
@@ -93,28 +150,31 @@ Under the hood, the quarkus jdt.ls extension delegates the resolution (i.e. down
93
150
</dependency>
94
151
```
95
152
96
-
will generate some hibernate properties like:
153
+
will generate the hibernate properties coming from the deployment JAR, like:
97
154
98
155
*`quarkus.hibernate-orm.dialect`
99
156
*`quarkus.hibernate-orm.sql-load-script`
100
-
101
-
despite the fact that the following dependency was not declared in the `pom.xml`:
157
+
158
+
even if the deployment JAR itself, was not declared in the Quarkus project's `pom.xml` like so:
0 commit comments