Re: Introducing Gradle Version Catalogs

I propose we try dependabot first for the new main - benefit is we don't need to host it ourselves. If version catalogs are not backported to 9x, perhaps we can re-purpose SolrBot to file PRs for branch_9_N? Jan > 14. nov. 2024 kl. 05:47 skrev Christos Malliaridis : > > The current bot would r

Re: Introducing Gradle Version Catalogs

The current bot would require some configuration changes to get it running again, as renovate relies on palantirs plugin for updating lock files, and I believe it uses "gradlew --write-locks" to update the file. This would not work anymore. The bot already runs a custom task for including "grad

Re: Introducing Gradle Version Catalogs

We’ll need to modify what files renovatebot considers, right now it is only two files, after it will probably be several. Another option is to switch to Dependabot, which did not support consistent-versions plugin, but do support version catalogs. Jan > On 13 Nov 2024, at 16:38, David Smiley

Re: Introducing Gradle Version Catalogs

Thanks again for this modernization effort, Christos! A lot of work, clearly. Do you imagine the "Renovate" bot will need updates to work in this new world? I suppose we shall deal with that when we get to the other side. On Wed, Nov 13, 2024 at 10:12 AM Christos Malliaridis < malliari...@apach

Re: Introducing Gradle Version Catalogs

This is the last call for SOLR-17406 / https://github.com/apache/solr/pull/2706. All matters have been resolved and the changes will be merged soon if there are no objections. If you are having any open PRs that make any changes in gradle files, I'd recommend to wait before merging. If you add

Re: Introducing Gradle Version Catalogs

Bringing up this topic again as the PR https://github.com/apache/solr/pull/2706 is ready for another review round. Since it changes the way dependencies are managed, it would be great if we can get more eyes on the PR before merging it. This is also the last "blocker" of the POC for the new Adm

Re: Introducing Gradle Version Catalogs

Hi Christos, I've now revised the initial PR (https://github.com/apache/solr/pull/2646) > and created a clean PR with the changes and version conflict resolution. > See for that https://github.com/apache/solr/pull/2706. The new PR does > not include dependency updates like the initial PR. > Nice!

Re: Introducing Gradle Version Catalogs

I've now revised the initial PR (https://github.com/apache/solr/pull/2646) and created a clean PR with the changes and version conflict resolution. See for that https://github.com/apache/solr/pull/2706. The new PR does not include dependency updates like the initial PR. Right now, the constraints

Re: Introducing Gradle Version Catalogs

> There isn't a singular "classpath" > (DependencySet? in Gradle). I think there are multiple "classpaths" > for many things (e.g. compiling main sourceSet vs compiling test > sourceSet) for each module (many modules). These configurations are from the java plugin in gradle and most of them are

Re: Introducing Gradle Version Catalogs

On Thu, Aug 22, 2024 at 3:25 AM Dawid Weiss wrote: > > What would be the drawbacks / risks for allowing multiple versions of the > > same library in case of transitive dependencies and their resolution? > > > > The drawback is that you'd end up having multiple JARs on the classpath - > their order

Re: Introducing Gradle Version Catalogs

> > I couldn't find a way to identify redundant constraints either for > cleaning up in the long run the constraints. Any ideas how this could be > tackled? > Exactly. It's a problem I keep struggling with elsewhere as well. The only workflow I managed to figure out was to keep the constraints cen

Re: Introducing Gradle Version Catalogs

> What palantir-consistent-versions did (always taking the ceiling) is easier but less transparent, I am for transparency too, I had enough troubleshooting sessions for fixing something that I couldn't see. What I also found is that there are some difficulties in keeping the constraints clean the

Re: Introducing Gradle Version Catalogs

Hi Christos, > I am just not very happy with the repetitive constraints and the need to > include transitive dependencies in the version catalog whenever there is a > version mismatch that needs to be synced. I share your pain - there is added verbosity here. I haven't found an elegant way to d

Re: Introducing Gradle Version Catalogs

I worked on the PR and solved the version conflicts now. I considered removing the plugin, as you proposed, but I ended up using it instead, because its functionality is still useful in my opinion. I am just not very happy with the repetitive constraints and the need to include transitive dependenc

Re: Introducing Gradle Version Catalogs

> Indeed, I saw that you also added spotless and tidy to the gradle build > files and provided a gradle plugin for the dependency checks. I definitely > and unintentionally talked down your work in that PR, sorry for that. > That's fine. I'm not that happy with everything that's in the Lucene buil

Re: Introducing Gradle Version Catalogs

Christos, since you've done seemingly all the work or close to it, IMO it's better to continue instead of delaying merging to main. It's tempting to respond to Solr 10 & 9 releases and timelines but that is deserving of another thread that would derail this thread IMO. Or chit-chat in Slack on tha

Re: Introducing Gradle Version Catalogs

I've created SOLR-17406 and PR 2646 so that we have something to work with. We probably have more than enough time to finish this migration before Solr 10 is released.

Re: Introducing Gradle Version Catalogs

My understanding is that Lucene 10 is likely to be released this fall, and I know I'd like to see Solr 10 come out close to when Lucene 10 comes out so we don't fall behind   So maybe there won't be many more releases of 9?  9.8 maybe?  but not a 9x line that gets into the double digits on

Re: Introducing Gradle Version Catalogs

> It's not just that. Indeed, I saw that you also added spotless and tidy to the gradle build files and provided a gradle plugin for the dependency checks. I definitely and unintentionally talked down your work in that PR, sorry for that. I started a couple weeks ago a migration without knowing t

Re: Introducing Gradle Version Catalogs

Hi Christos, I'd like to follow the same approach in Solr, as it would allow us to sync > some of the dependencies and keep all versions in one file. > It's not just that. It's also a switch from palantir's dependency resolution mechanism to gradle's. I think it's a good direction, because palant

Re: Introducing Gradle Version Catalogs

Thanks for offering to help port this! I noticed that change is Lucene 10 only; I think a build change of that magnitude should also be Solr 10 only, thus the main branch. We might want to delay such a change for another release or so in order for dependency backports to 9 to go smoothly. There'

Introducing Gradle Version Catalogs

In the Lucene project there was a couple weeks ago a migration to version catalogs (see PR #13484 ). I'd like to follow the same approach in Solr, as it would allow us to sync some of the dependencies and keep all versions in one file. If this is some