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

Blacklist dependencies/versions #9

Closed
dmarin opened this issue Dec 14, 2021 · 9 comments
Closed

Blacklist dependencies/versions #9

dmarin opened this issue Dec 14, 2021 · 9 comments

Comments

@dmarin
Copy link

dmarin commented Dec 14, 2021

Hi! I would like to know if you are thinking on adding blacklist for certain dependencies?

Ie I may want to update manually compose and kotlin as I know they have a certain relationship, but update the rest automatically.

I would be happy to work on this if you think it would be a nice addition to the plugin

@hvisser
Copy link
Contributor

hvisser commented Dec 14, 2021

That would come down to configuring the version updates plugin correctly IMHO, one way to approach that is by taking the version in the version catalog and require that version for dependency updates.

An example of that is in this PR

Would that be sufficient for what you are looking for? The plugin could maybe do something to configure the version updates plugin to "pin" versions like that, but I'm not sure if that would improve things. Another interesting question would be how the plugin could still communicate an update is available...for example by logging a message or adding a comment to the toml file?

@dmarin
Copy link
Author

dmarin commented Dec 14, 2021

Thanks for the quick answer. What you mentioned is exactly the reason why I did not jump straight into the code, I did not know how to notify back about the "ignored" version.

The PR you linked is what we discussed on the team as an alternative, however, we also found nice the concept of "blacklist" that can be found in this other similar plugin: https://github.com/patrikerdes/gradle-use-latest-versions-plugin.

Anyway, to answer your question. Yes, that solution works for us, so, feel free to close this issue, and thanks a lot for taking the time to find an example about how to achieve this without forking your plugin.

BTW nice work, we discovered this plugin a few weeks ago and we are loving it ❤️

@hvisser
Copy link
Contributor

hvisser commented Dec 15, 2021

Thanks ❤️ I'll leave this open, I think some mechanism of saying "hey, I'll upgrade this myself" would be useful, if the plugin also tells you that an update is available. That could be a simple list of libraries and plugins you want to pin to the version specified in the catalog for example.

@dmarin
Copy link
Author

dmarin commented Dec 15, 2021

Just in case someone gets here trying to solve this same problem. This is the code I ended up writing to ignore the dependencies defined on the ignoredGroups list.

def ignoredGroups= ["org.jetbrains.kotlin", "androidx.compose.ui", "com.squareup.moshi"]

dependencyUpdates {
    resolutionStrategy {
        componentSelection {
            all {
                if (isNonStable(it.candidate.version) && !isNonStable(it.currentVersion)) {
                    reject('Release candidate')
                }
                if (ignoredGroups.contains(it.candidate.group)) {
                    reject("Pinned dependency")
                }
            }
        }
    }
}

@sjthiessen
Copy link

I just stumbled upon a similar problem where i would like to specify a version that should not be updated automatically. I would prefer denoting this in the .toml file directly using the strictly keyword: https://docs.gradle.org/current/userguide/rich_versions.html

It seems like this is not supported by this plugin. Example:

nebula-release = { strictly = "14.0.3" } 
[plugins]
nebula-release = { id = "nebula.release", version.ref = "nebula-release" }

results in the following error:
Expected class java.lang.String for key nebula-release, but was class java.util.LinkedHashMap

The gradle build task itself works just fine.

@hvisser
Copy link
Contributor

hvisser commented Jan 31, 2022

@sjthiessen This has actually been fixed on main, see issue #17. In addition that fix will also tell you if there's an update available so that you can still keep an eye on new versions.

The pinning of dependencies (this issue) is also in the works, I'm planning to release that this week 🤞

@hvisser
Copy link
Contributor

hvisser commented Jan 31, 2022

For anyone who wants to try, the 0.3.0-SNAPSHOT has the new pinning behaviour as documented in the README too now. If you have any feedback or see any issues, let me know, otherwise I'll release these changes somewhere this week.

@sjthiessen
Copy link

Oh, I missed that! Thanks for the quick response!

@hvisser
Copy link
Contributor

hvisser commented Feb 2, 2022

Released in 0.3.0

@hvisser hvisser closed this as completed Feb 2, 2022
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

No branches or pull requests

3 participants