Move junit libs to managed block.

[altro3]

Fixed #831

[altro3]

@melix @graemerocher Something is wrong with test resources for R2DBC_MYSQL. All builds failed with the same error:

[CLAassistant]

All committers have signed the CLA.

[wetted]

@altro3 Thanks to @timyates catch, this is resolved and merged on #948. If you merge from master the r2dbc test should pass now.

[sdelamo]

don't we expose the JUnit5 BOM?

[altro3]

I think in this case it is necessary for internal use in the miсronaut modules, because everyone is tired of constantly describing the junit5 library versions in the catalog, I would like them to connect from the micronaut-test catalog and be accessible via the mnTest.junit.jupiter.engine for example

[graemerocher]

not sure who everyone refers to here, if the JUnit 5 BOM is already imported then it doesn't impact users. For us we have a way to import catalogs and use JUnit, see https://github.com/micronaut-projects/micronaut-reactor/blob/e671a8653a8f8a0fc316a2ede6b541ea088acd0b/settings.gradle#L29 for an example

[altro3]

Well, the problem is that these libraries are not in the catalog now and in each project you need to describe this library in libs.versions.toml. That is, now you can connect the junit-jupiter-engine and junit-jupiter-params libraries only in this way (example from micronaut-openapi)

This task was not invented by me, but by @melix , I suspect that only managed libraries get into the version catalog. But this is not 100%

But judging by the description of the task, it is so

[melix]

It seems that there are a couple things. The first is that we do import the junit platform BOM already. This means that in any project, you can add a dependency on JUnit without having to declare the version, as long as the micronaut-test bom is imported.

However, since JUnit is not a Micronaut platform, then you won't have accessors like mnTest.junit.platform. For this we need to add managed entries like in this PR. This will obviously only cover the modules we care about.

Strictly speaking, "everyone is tired of constantly describing the junit5 library versions in the catalog" is not a good argument:

• first you only need to describe the group and artifact, since the version is already managed by the JUnit platform BOM
• second, as soon as we expose something as managed, then it is exposed to consumers, not only us, but also users

In this case it seems reasonable to add such entries here, I think.

[altro3]

True, but as you correctly noted, we already provide the user with access to the bom file. so I don't see a problem in making it easier to use junit using the version catalog.

[melix]

we already provide the user with access to the bom file

It's the other way around ;) The BOM files are primarily meant for users, not us : they will impact the dependency resolution of user app. That's why we must be careful what we add there.

[altro3]

Apparently, there is a complex logic hidden here that I don't really understand. For me, as a user, the only difference will be that I will be able to remove these 2 lines from the file:

junit-jupiter-engine = { module = "org.junit.jupiter:junit-jupiter-engine" }
junit-jupiter-params = { module = "org.junit.jupiter:junit-jupiter-params" }

which will give me pleasure :-)

[altro3]

@graemerocher @melix Could you merge it?

[sdelamo]

I don't like this change and I don't think we should follow this pattern in other modules. We are already exposing the BOM.

I see no issue of having in the modules.

junit-jupiter-engine = { module = "org.junit.jupiter:junit-jupiter-engine" }
junit-jupiter-params = { module = "org.junit.jupiter:junit-jupiter-params" }