Using Buildship 3.1.5, Eclipse 2020-09 (4.17).
I have a Gradle multiproject. I’m using Spring Boot. One of my projects has the following dependencies:
implementation platform("org.springframework.boot:spring-boot-dependencies:2.4.3") implementation 'org.springframework.boot:spring-boot-starter-activemq'
Then, one of my class is using Spring JMS features (i.e.:
Buildship is configured to use the Gradle wrapper.
If I use wrapper version 6.8.3 all works fine.
If I upgrade the wrapper to version 7.0, then I get the following error on the project that is using JMS:
The project was not built since its build path is incomplete. Cannot find the class file for javax.jms.Message. Fix the build path then try building this project
On the specific class that is using
JmsTemplate I get, at the first line:
The type javax.jms.Message cannot be resolved. It is indirectly referenced from required .class files
javax.jms.Message is actually present in my project build path, because it’s in
jakarta.jms-api-2.0.3.jar within the “Project and External Dependencies” classpath container. Indeed, Ctrl+Shift+T brings you to that class successfully. Building the project with Gradle from the command line succeeds (no compilation errors or such). However, Eclipse gives this build path error.
Switching back to wrapper 6.8.3 fixes the problem. Indeed, I need to:
wrapper.gradleVersion = '7.0'to
wrapper.gradleVersion = '6.8.3'in the master project build file
- perform a “Refresh Gradle Project”
and the error goes away.
I suspect this has something to do with the fact that
jakarta.jms-api-2.0.3.jar is indeed replacing the
geronimo-jms_1.1_spec-1.1.1.jar on which
org.apache.activemq:activemq-client:5.16.1 (which in turn is transitively brought in by
org.springframework.boot:spring-boot-starter-activemq) would actually depend on. I think it’s Spring Boot that is forcefully excluding
org.apache.geronimo.specs:geronimo-jms_1.1_spec:1.1.1 from the transitive dependencies of ActiveMQ, replacing it with
jakarta.jms:jakarta.jms-api:2.0.3: however this should not harm the buildpath in this way, indeed with Gradle 6.8.3 wrapper all works fine.