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
Currently JakartaProjectLabelProvider is determining that a project is a Jakarta project by merely checking for the availability of jakarta.ws.rs.GET on the classpath. Application servers such as Open Liberty are composable and users may specify configuration (e.g. server.xml features for a Liberty application) that only loads/utilizes a subset of Jakarta EE functionality like JPA or selects a specific version of Jakarta EE (e.g. 10). We thought this might be a good case for defining finer grained labels for each of the separately loadable modules and versions of Jakarta EE. A similar argument could also be made for the Microprofile label provider from LSP4MP.
The text was updated successfully, but these errors were encountered:
This came up during a code review of Liberty Tools for IntelliJ which included a ported version of JakartaProjectLabelProvider. See discussion here: OpenLiberty/liberty-tools-intellij#614 (comment).
Currently
JakartaProjectLabelProvider
is determining that a project is a Jakarta project by merely checking for the availability ofjakarta.ws.rs.GET
on the classpath. Application servers such as Open Liberty are composable and users may specify configuration (e.g.server.xml
features for a Liberty application) that only loads/utilizes a subset of Jakarta EE functionality like JPA or selects a specific version of Jakarta EE (e.g.10
). We thought this might be a good case for defining finer grained labels for each of the separately loadable modules and versions of Jakarta EE. A similar argument could also be made for the Microprofile label provider from LSP4MP.The text was updated successfully, but these errors were encountered: