If Eclipse/M2E reports a maven dependency version conflict, with message “managed from x.y.z” (ex : “jooq/ 3.7.1 (managed from 3.6.0)“), the conflicting dependency is defined by an ancestor of the current maven project (could be its parent, great-parent, great-great-parent, etc.).
For example, let’s say maven signals a dependency conflict for a spring-boot 1.3 application. Version 3.7.1 of the JOOQ library is used while you specified version 3.6.0 (which is a pain because JAVA 7 is targeted, while JOOQ 3.7.1 only supports JAVA 8).
The error returned by the SpringBoot application is :
[code]
java.lang.UnsupportedClassVersionError: org/jooq/SQLDialect :
Unsupported major.minor version 52.0
[/code]
JOOQ is used by a dependency of the spring-boot application. The main application itself has no reference to JOOQ.
Indeed :
-
project A declares a maven dependency on JOOQ 3.6.0 :
[code lang=xml]
org.jooq
jooq
3.6.0
[/code]
- project B declares a maven dependency on project A, and defines spring-boot-starter-parent as a parent
In project B dependencies, Eclipse/M2E flags JOOQ as “version 3.7.1 (managed from 3.6.0)” while version 3.6.0 is expected.
- spring-boot-starter-parent has spring-boot-dependencies as a parent, which itself manages dependencies for JOOQ
[code lang=xml]
org.jooq
jooq
${jooq.version}
[/code]
To fix it, you could add a jooq 3.6.0 dependency to project B, so that the maven dependency conflict solving strategy uses this version since it is the nearest dependency. But that would be ugly. A cleaner solution consists in overriding the jooq.version property defined in spring-boot-starter-parent, as documented here :
[code lang=xml]
