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

Sort out dependency resolution #5

Open
ataulm opened this issue Oct 5, 2019 · 1 comment
Open

Sort out dependency resolution #5

ataulm opened this issue Oct 5, 2019 · 1 comment

Comments

@ataulm
Copy link
Owner

ataulm commented Oct 5, 2019

We want strict versioning so that this library will only work if the host project's version of MDC matches this one.

This is because MDC look-and-feel can differ drastically from version to version (even minor versions 🙄) so we want users to be explicit when they use this and feel confident that the version they've defined in their project is the one they're seeing here.

@ataulm
Copy link
Owner Author

ataulm commented Oct 6, 2019

So you want that library to use some (default) version that you define, but allow users to use a different version if they prefer that, right?

By default, Gradle picks the latest version of a dependency (since there can only be one in a project).

The dependency team at Gradle has added quite some goodies lately in that space.

You probably want to define a certain good range that you allow for your library to work, and then define a preferred one that is used if there is none defined elsewehere. I think that is possible already. Let me find the docs…

https://docs.gradle.org/current/userguide/declaring_dependencies.html#sub:declaring_dependency_rich_version

me: For the MDC dependency, we want the users’ version to work - though ideally, they’ll keep MDC + this library in sync. We want to avoid the library to upgrade the user without them knowing.
You’d probably define a prefer version than. That is only used when there is no other definition.
me: so if they have a lower version in their project, gradle will use the lower one?
Yes, it should. I haven’t tried it myself, let me know if it does not work as expected.
You can combine that with a strictly range if you want to limit that flexibility.

I think that functionality is based on the Gradle-metadata format, so you need to make sure that this is published with your library.
https://blog.gradle.org/gradle-metadata-1.0

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

1 participant