-
Notifications
You must be signed in to change notification settings - Fork 15
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
Ability to also *replace* artifacts #35
Comments
Thanks for all the suggestions for new rules @boris-petrov. It sounds to me like you are combining multiple configurations in your setup by adding the results of the resolution. For example, if you do something like this What you should do instead is combining the configurations to one and do only one resolution. Then this plugin should detect the conflict for you and, to stick with the example, select only one Instead of doing something like:
You do:
|
@jjohannes thanks for the support! I see what you mean... actually I believe (one of) my problem is in my configuration of the But what I requested initially I believe still makes sense for a number of reasons:
Note that I'm absolutely not sure I'm right to think these things. I'm just thinking out loud. If you think what I say doesn't make sense, please let me know and we can close the issue. :) Thanks again for the hard work! |
Regarding detectCollisions plugin: Yes, if you want to check multiple classpaths in one project, you need to register additional
Regarding the dependency substitution: Yes, you are right here as well. It is a (kind of unsolved) problem that you don't get the desired result if there is no conflict. Hence, you easily get into the situation where the conflict appears on your runtime classpath, but not on some of your compile classpaths. I think it would be great if there could be a feature in Gradle similar to "Consistent Resolution", which somehow automatically solves this. With consistent resolution you can, if you set it up like here, make sure that all versions (and with that all version conflicts) appear on all classpaths. For this plugin, I imagined initially that it only provide metadata - i.e. that everything the plugin does is adding information that could also be published as part of the metadata. But yes, the information we have could possibly also be used to create substitution rules to get the desired consistency – similar as in the logging-capabilities plugin. Right now, this plugin already does more than just providing metadata as it also provides resolution strategies (see also comment here #36 (comment)). Maybe we could think about providing three plugins, so that we have one "pure metadata rules" plugin and offer plugins for the resolution strategies and for substitution rules in addition:
|
Thank you being open-minded about this and considering it! I agree with everything you said and would like to see very much these three plugins come to life! :) I'm wondering something though... why would anyone not want the |
There are cases where there is no clear default for every context. Especially when alternatives overlap, but are not exactly the same. Just taking the highest version (or selecting by some other general criteria) might not be the right for every context. And then a problematic conflict can go unnoticed. Which is an argument for adding all resolution strategies yourself in your build for your dependency graph(s). So that your are aware of all conflicts which you handle explicitly. (That's also a reason why Gradle itself does not have a default, like select highest version, built-in for capability conflicts.) There are many examples already:
|
So I guess the best would be to provide default rules for the "obvious" ones and not provide rules for the unknown ones. I definitely think that providing defaults is great because in most cases people won't have to think - just apply the plugin and continue with your life (that's answering your question in #36). |
Thanks for the new release!
I've been having this issue since the beginning of my using of the plugin and I'm really not sure what's the best way to tackle it.
I have different configurations which have different dependencies. In some of them, for example, I have a transitive dependency on
bcprov-jdk15on
; in other configurations I have a transitive dependency onbcprov-jdk18on
; and in third ones I have transitive dependencies on bothbcprov-jdk15on
andbcprov-jdk18on
. I'm using theio.fuchs.gradle.classpath-collision-detector
(as you suggested in your last video :) ) which complains about a conflict because I've got bothbcprov-jdk15on
andbcprov-jdk18on
(in different configurations - the two ones in the same configuration are handled correctly byjava-ecosystem-capabilities
). What I've been doing is as follows:The question is if it's somehow possible for this to be done automatically by the plugin or there could be some option for it?
The text was updated successfully, but these errors were encountered: