You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by GitBox <gi...@apache.org> on 2022/02/25 09:46:53 UTC
[GitHub] [solr] janhoy opened a new pull request #707: Experiment with gradle-versions-plugin
janhoy opened a new pull request #707:
URL: https://github.com/apache/solr/pull/707
Playing with this plugin. It produces a quite useful report (https://gist.github.com/janhoy/91acf9ebb856bf1a97c4cf1ff68b8c6e) but it also fails to resolve some versions, see my email in this thread: https://lists.apache.org/thread/sw36msmyf72hjt5y4jpczrjl3n04yl1n
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dweiss commented on pull request #707: Experiment with gradle-versions-plugin
Posted by GitBox <gi...@apache.org>.
dweiss commented on pull request #707:
URL: https://github.com/apache/solr/pull/707#issuecomment-1054110236
You could live without palantir's plugin by declaring versions consistently, everywhere. The problem I see is detection of duplicates/ version conflicts across dependencies, etc. This can all be done, but it requires some extra effort (before you ask - I can't really do it, not right now). :(
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] janhoy commented on pull request #707: Experiment with gradle-versions-plugin
Posted by GitBox <gi...@apache.org>.
janhoy commented on pull request #707:
URL: https://github.com/apache/solr/pull/707#issuecomment-1054107190
It's unfortunate, but probably the price we have to pay for the benefits consistent-versions gives us. I also tried with dependabot, it does not either play well with consistent-versions, and they are *not* going to support that plugin either, since gradle is adding support for lock-files natively. I had a look at Gradle's incubating lockfile feature, but to me it looks overly complex. But if it graduates to GA it at least will have the benefit of being supported by other tooling..
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] ben-manes commented on pull request #707: Experiment with gradle-versions-plugin
Posted by GitBox <gi...@apache.org>.
ben-manes commented on pull request #707:
URL: https://github.com/apache/solr/pull/707#issuecomment-1051744167
This plugin only provides information about possible upgrades and leaves it up to the developer to decide what makes sense. As a scriptable report that is fairly benign result and was intended to mimic Maven's [versions:display-dependency-updates](https://www.mojohaus.org/versions-maven-plugin/display-dependency-updates-mojo.html) task. It was written as a weekend project for Gradle 1.0 using the apis suggested by their co-founder and maintained with updates based on recommendations from the core team. At that time there wasn't any options, but maybe now you'll have other choices that you prefer over this minimalistic approach.
Your concerns can be addressed by specifying a resolution strategy to reject unreleased versions and use a custom report to filter the results to dependencies within your `versions.prop` file. That is configuration to customize it to fit your build.
Unfortunately plugins that try to manage dependencies can easily break the ecosystem by making overly restrictive assumptions about how Gradle works. A similar case happened with Spring's dependency-management-plugin which they quickly fixed. Hopefully the Palantir team can fix their oversights or provide suggestions for how to manage updates.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] risdenk commented on pull request #707: Experiment with gradle-versions-plugin
Posted by GitBox <gi...@apache.org>.
risdenk commented on pull request #707:
URL: https://github.com/apache/solr/pull/707#issuecomment-1051077526
So to be honest - I'm not a super fan of tools like these. I understand how it looks helpful, but the tools don't account for major versions or other things that shouldn't be upgraded independently.
Some bad examples from the report:
* any of the google cloud dependencies - should be updated through google cloud bom (recently added) - https://github.com/apache/solr/blob/main/versions.props#L10
* com.squareup.okhttp3:okhttp [4.9.3 -> 5.0.0-alpha.5] - alpha and not even official yet
There are definitely some good examples in there as well.
I kinda wish it were filtered by what we had in `versions.prop` since those are currently the dependencies that we define and manage ourselves.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org
[GitHub] [solr] dweiss commented on pull request #707: Experiment with gradle-versions-plugin
Posted by GitBox <gi...@apache.org>.
dweiss commented on pull request #707:
URL: https://github.com/apache/solr/pull/707#issuecomment-1051079348
It's the price of gradle's flexibility - there is no single configuration/ ecosystem that works across everything. Palantir's version control plugin is a highly non-standard way of managing dependencies (although it's really useful and mostly works fine). I'm afraid many tools simply won't play along with it though.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org