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.
This came up during a code review of Liberty Tools for IntelliJ which included a ported version of JakartaProjectLabelProvider. See discussion here: https://github.com/OpenLiberty/liberty-tools-intellij/pull/614#discussion_r1463658593.
Currently
JakartaProjectLabelProvideris determining that a project is a Jakarta project by merely checking for the availability ofjakarta.ws.rs.GETon the classpath. Application servers such as Open Liberty are composable and users may specify configuration (e.g.server.xmlfeatures 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.