Any follow up on using build cache and/or experiment with migration to gradle? I have a little bit of expertise with gradle and wanted to join in with the experiment. Compilation avoidance, dependency resolution engine and ease of writing ad-hoc plugins are very strong points with gradle. I migrated a bunch of projects at work to gradle and improved things quite a lot.
Configuration phase could be quite long, I'm impatiently waiting when configuration cache lands. It also avoids dependency resolution step on each gradle run. Nicholas, could you elaborate on what you mean with "New versions of gradle result in full redownload all the deps"? Never seen such behavior and it sounds like a bug or some elaborate repositories' misconfiguration. I only got extremely slow resolution with the spring dependency plugin and misconfigured reverse proxy before Nexus. As for build cache it brings some good on the ci but not much on local development in cases where we tried to use it. IIRC Build Cache server itself is free if we want to use it and burden Infra with running it. But likely it doesn't support clustering/HA which could be an issue for the ASF scale. We certainly could use build scans for free publishing them from CI builds, it would help with analyzing dependency graph and build performance. -- Best regards, Konstantin Gribov пт, 14 окт. 2022 г., 17:13 Nicholas DiPiazza <[email protected]>: > Is there a branch started on the Gradle thing? I have some cycles and can > use them to upgrade to Gradle on Tika, if desired. > > On Thu, Oct 6, 2022 at 8:50 AM Nick Burch <[email protected]> wrote: > > > On Thu, 6 Oct 2022, Tim Allison wrote: > > > Happy to chat. Please put them in touch. > > > > Excellent, thanks Tim! > > > > Other than your past talks, have we got any info (eg on the wiki?) about > > how to run the regression corpus? > > > > > I've been really impressed with what the POI team has done migrating > > > from ant to gradle. On Tika, I don't think we have any special needs > > > that would require deep gradle knowledge, but given the number of > > > modules now, it will be non-trivial. Also, I take Nick D's concerns > > > seriously. > > > > We don't have to swap from Maven - they have a plugin that integrates it > > > > Nick > > >
