Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

build: bump non-micronaut managed patch dependencies #6776

Merged
merged 2 commits into from
Jan 20, 2022

Conversation

pgressa
Copy link
Contributor

@pgressa pgressa commented Jan 19, 2022

No description provided.

Copy link
Contributor

@ilopmar ilopmar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty much all your changes shouldn't be done here but in the appropriate micronaut modules.

managed-elasticsearch = "7.16.1"
managed-elasticsearch = "7.16.3"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comment on lines 70 to 72
managed-kafka = "2.8.0"
managed-ktor = "1.6.1"
managed-lettuce = "6.1.1.RELEASE"
managed-kafka = "2.8.1"
managed-ktor = "1.6.7"
managed-lettuce = "6.1.6.RELEASE"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These are managed by micronaut kafka, kotlin and redis modules

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micronaut Kotlin, Kafka and Redis should provide BOMs

managed-micrometer = "1.8.0"
managed-micrometer = "1.8.2"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Managed by micronaut-micrometer

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

managed-neo4j = "3.5.29"
managed-neo4j = "3.5.30"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Managed by micronaut-neo4j

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micronaut Neo4j should provide a BOM

managed-picocli = "4.6.1"
managed-picocli = "4.6.2"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Managed by micronaut-picocli

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micronaut PicoCLI should provide a BOM

managed-rxjava2 = "2.2.10"
managed-rxjava2 = "2.2.21"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Managed by micronaut-rxjava2 module

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micronaut RxJava 2 should provide a BOM

managed-swagger = "2.1.10"
managed-swagger = "2.1.12"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Managed by micronaut-openapi module

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micronaut OpenAPI should provide a BOM

managed-spring = "5.3.9"
managed-spring = "5.3.15"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Managed by micronaut-spring module

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Micronaut Spring should provide a BOM

@pgressa
Copy link
Contributor Author

pgressa commented Jan 19, 2022

@ilopmar how to reliably identify such modules? And does that mean that our current dependency upgrades job is broken right?

@graemerocher
Copy link
Contributor

@melix thoughts?

@ilopmar
Copy link
Contributor

ilopmar commented Jan 19, 2022

@ilopmar how to reliably identify such modules? And does that mean that our current dependency upgrades job is broken right?

We may miss something but if there is a micronaut-xxxxxx module with the same/related name that's probably the one responsible for managing the upgrade of the libraries.
I agree that some times it can be tricky because modules like micronaut-sql handle different dependencies: https://github.com/micronaut-projects/micronaut-sql/blob/master/gradle.properties#L36

@melix
Copy link
Contributor

melix commented Jan 19, 2022

It's difficult to figure out what manages what, because there's a circular dependency: micronaut-core defines the "master" BOM, but also includes other BOMs, which are from modules which depend on core and may be using dependencies defined in the micronaut-core BOM.

I guess something we can do is to have a job or task which actually checks if a dependency is defined both in the micronaut core BOM and any of the modules it includes. If so, then we must decide whether it makes sense to include it in the core BOM (because, a dependency may want to be managed by core independently, if it makes sense in multiple modules).

@graemerocher
Copy link
Contributor

yeah I think personally the solution is that these versions shouldn't be managed by core and the module that updates the version in the core BOM should instead express it in their own BOM

@ilopmar
Copy link
Contributor

ilopmar commented Jan 19, 2022

So that means that every micronaut module should publish its own bom? even for modules with one "exposed/managed" dependency (flyway, liquibase,...)

@graemerocher
Copy link
Contributor

yes ultimately those versions are only tested in the modules so the only way to know compatibility with the version is in the sub module anyway which makes these PRs close to useless

@pgressa pgressa merged commit 6cfecb8 into 3.2.x Jan 20, 2022
@pgressa pgressa deleted the pgr-dependency-upgrades branch January 20, 2022 14:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants