So I'm looking at this and trying to understand how this is a runtime dependency when it appears that hibernate-core is saying that it's compile time https://mvnrepository.com/artifact/org.hibernate.orm/hibernate-core/6.5.2.Final am I reading this wrong? Is hibernate-core not the only thing with a direct dependency here? how is it ending up as a runtime dependency? https://scans.gradle.com/s/73uwcvwekrefc/dependencies?focusedDependency=WzEsOCwyOTUsW[…]5Nl1dLFsxLDgsWzYxNiw3OTYsNzg0XV0sWzEsOCxbNjE2LDgwMiw3NjhdXV0

Calculating task graph as no cached configuration is available for tasks: :jpa:dependencyInsight --configuration runtimeClasspath --dependency transaction
Type-safe project accessors is an incubating feature.
> Task :buildSrc:checkKotlinGradlePluginConfigurationErrors
> Task :buildSrc:generateExternalPluginSpecBuilders UP-TO-DATE
> Task :buildSrc:extractPrecompiledScriptPluginPlugins UP-TO-DATE
> Task :buildSrc:compilePluginsBlocks UP-TO-DATE
> Task :buildSrc:generatePrecompiledScriptPluginAccessors UP-TO-DATE
> Task :buildSrc:generateScriptPluginAdapters UP-TO-DATE
> Task :buildSrc:compileKotlin UP-TO-DATE
> Task :buildSrc:compileJava NO-SOURCE
> Task :buildSrc:compileGroovy NO-SOURCE
> Task :buildSrc:pluginDescriptors UP-TO-DATE
> Task :buildSrc:processResources UP-TO-DATE
> Task :buildSrc:classes UP-TO-DATE
> Task :buildSrc:jar UP-TO-DATE

> Task :jpa:dependencyInsight
jakarta.transaction:jakarta.transaction-api:2.0.1
  Variant runtime:
    | Attribute Name                 | Provided     | Requested    |
    |--------------------------------|--------------|--------------|
    | org.gradle.status              | release      |              |
    | org.gradle.category            | library      | library      |
    | org.gradle.libraryelements     | jar          | jar          |
    | org.gradle.usage               | java-runtime | java-runtime |
    | org.gradle.dependency.bundling |              | external     |
    | org.gradle.jvm.environment     |              | standard-jvm |
    | org.gradle.jvm.version         |              | 17           |
   Selection reasons:
      - By constraint: dependency was locked to version '2.0.1'
      - By ancestor

jakarta.transaction:jakarta.transaction-api:{strictly 2.0.1} -> 2.0.1
\--- runtimeClasspath

jakarta.transaction:jakarta.transaction-api:2.0.1
+--- org.hibernate.orm:hibernate-core:6.5.2.Final
|    +--- runtimeClasspath (requested org.hibernate.orm:hibernate-core:{strictly 6.5.2.Final})
|    +--- org.springframework.boot:spring-boot-dependencies:3.3.2
|    |    +--- runtimeClasspath (requested org.springframework.boot:spring-boot-dependencies:3.+)
|    |    \--- project :model (requested org.springframework.boot:spring-boot-dependencies:3.+)
|    |         \--- runtimeClasspath
|    +--- org.hibernate.orm:hibernate-envers:6.5.2.Final
|    |    +--- runtimeClasspath (requested org.hibernate.orm:hibernate-envers)
|    |    \--- org.springframework.boot:spring-boot-dependencies:3.3.2 (*)
|    \--- org.springframework.boot:spring-boot-starter-data-jpa:3.3.2
|         +--- runtimeClasspath (requested org.springframework.boot:spring-boot-starter-data-jpa)
|         \--- org.springframework.boot:spring-boot-dependencies:3.3.2 (*)
\--- org.springframework.boot:spring-boot-dependencies:3.3.2 (*)

(*) - Indicates repeated occurrences of a transitive dependency subtree. Gradle expands transitive dependency subtrees only once per project; repeat occurrences only display the root of the subtree, followed by this annotation.

A web-based, searchable dependency report is available by adding the --scan option.

BUILD SUCCESSFUL in 2s
11 actionable tasks: 2 executed, 9 up-to-date

Publishing build scan...
<https://gradle.com/s/zngohwgoi6gv6>

Configuration cache entry stored.

compile = compile and runtime runtime = runtime

apparently I haven't had a large enough caffeine injection

🙂

sigh trying to track down the stupid of either how I get rid of it, or a better way of giving jakarta transaction versions

Didn't get what you mean. Doesn't the scan say you set a strict version constraint for that lib in your jpa project?

the problem is jakarta-transaction requires CDI

Yes, a

provided

library is meant to be provided by the runtime environment, this can for example be a JEE container.

if a dependency in maven is defined as "provided" gradle doesn't do that if a version is provided either huh

Just like Maven, Gradle basically ignores any

provided

or

optional

entries, they are only considered informative for the human user. They will not be added automatically anywhere and they also will not influence versions in any way.

"if transient or explicit transaction-api present also add deps"

That would then be a component metadata rule in which you add the dependency

right, but provided isn't optional... that's what bothers me about the whole thing 😕 neways

Regarding dependency resolution it indeed is optional, as it is the responsibility of the runtime environment to provide the dependency. 🤷‍♂️

yeah... but I still think since the dependency is there and is "requires" that the spring boot starter should be providing it.... and spring boot should be using the EE bom to get a version

requires static

does not make sense if it is provided, because as you correctly said, it is effectively required.

requires static

is for stuff that is optional and it works if it is not present at runtime. But yeah, probably Boot should provide it or at least provide a version. 🤷‍♂️

well, in this case the spec is arguably wrong. It probably should be optional

Actually I don't really get why you think Spring should do anything in relation to the JEE spec. Spring is not JEE. Spring is Spring. JEE is JEE. For example DI is done via Spring in Spring, but via CDI in JEE.

you can use CDI in JEE

@Inject

is not CDI

because the transaction library added a CDI dependency

Possible

it's not all my discussion either. I'm not the first person to open a bug with jakarta transaction. I'm just the one who did it with spring