yesamer opened a new issue, #782: URL: https://github.com/apache/incubator-kie-issues/issues/782
To know more about the feature, I invite you to take a look at my below blog post. https://blog.kie.org/2022/05/dmn-types-from-java-classes.html The architecture behind that feature has some weak points, in detail: - **It relies on a technology designed for Text Editors**: Despite the idea of taking advantage of the LSP protocol and the JDT module gave us access to a power tool to infer Java class info, we needed to implement an unconventional way to use it (simulating a java file class autocompletion request) - **Highly coupled with the "Java Language VSCode extension" version**: That VSCode is not under our control, any extension update might break the compatibility with our code (already happened in the past). We're forced to stay with the latest extension version because VSCode always updates the extensions by default, and asking our users to change this behavior results in a forceful act. - **JDT.LS eclipse plugin relies on ephemeral repositories.**: Every JDT.LS version relies on an eclipse repository that gets removed every 3 months ---> https://github.com/eclipse/eclipse.jdt.ls/issues/1970 - **We are forced staying stick with the latest "Java Language VSCode extension" & JDT.LS version**: For the above 2 reasons - **The feature is enabled in VSCode channel only**: The ideal solution should work in KIE Sandbox as well, and this is not possible for an architecture that depends on a VSCode extension. Based on the above reasons, we decided to temporarily not enable the "Import Java Classes" in the new DMN Editor, to investigate and assess a more robust solution, which is the scope of this ticket. Possible solutions so far: 1. Continuing with the current approach. With the cost to pay to keep the JDT.LS dependency updated. In addition, I suspect we'll need to base our code to tycho 4.x and JDK 17 to stay updated. In addition, this will not work on KIE Sandbox. 1b. Using the same approach, but using https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java extension instead of the "Java Language VSCode extension". In my opinion, this leads to the same drawbacks as the previous point. 2. Implementing a specific service on the "extended-services" modules, that returns the list of the Java Classes and their public methods present in the user's project. "extended-services" acts like a backend for KIE Canvas (and in the future for the VSCode extension), it should be feasible implementing such a feature. A possible limitation is related to the Quakus native mode: in such a case, reflection has some limitations. 3. Using a Java parser that reads the Java Classes AST and returns the requested info (Java class names and public methods). A NodeJS library for that already exists ([here](https://www.npmjs.com/package/java-parser)), I tested it in this repo https://github.com/yesamer/java-parser-poc. 4. ...? Another point to underline is that the feature is a key one for the Test Scenario too, as we need it for RULE-based Test Scenario. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
