Hi Ryan and David- Long time lurker, first time poster.
I've got a lot of experience with Avro and Gradle, where I forked/extended David's plugin(and the added capabilities to the SpecificCompiler) to support some use cases that aren't part of his plugin or apache-tools. I'm not with that company anymore and am in a position where I could contribute some effort... Mike On Fri, Sep 9, 2022 at 11:23 AM Ryan Skraba <[email protected]> wrote: > An offer of time also also well-appreciated! I'd love to hear from > any contributors that have gradle experience as well: would it be > appropriate and useful to have an official gradle plugin under the > Apache Avro repo? > > To answer your question, I can only really speak for what we do with > Maven: it's fairly straightforward: the plugin version matches the > version of Avro and supports the same Java versions. We never > generate code for previous versions of Avro. > > I.e., The Avro maven plugin 1.11.1 generates code with the Avro > SpecificCompiler 1.11.1, which is usually used with the Avro 1.11.1 > libraries (with Java 8 and up). > > On a related subject, I _used_ to think it was mandatory to match the > generated code with the avro libraries in use, and we've broken > compatibility with generated code in the past. There's an amazing > avro-util library to help generated code work across all versions[1]. > It's a pretty cool way to reuse generated code across Avro versions, > but we're also trying to keep in mind that people sometimes have mixed > environments (and AVOID break generated code compatibility). > > I'm not familiar with how much gradle breaks between versions... Maven > has been remarkably stable, and the Avro maven plugin still works with > Maven 3.2.x. > > [1]: https://github.com/linkedin/avro-util/ > > > On Thu, Sep 8, 2022 at 7:05 PM David M. Carr <[email protected]> wrote: > > > > If we were pursuing a donation of the plugin to the Avro project, I could > > definitely make some time available to guide (or even directly assist) > with > > the transition. > > > > The main area that requires consideration is the policy for version > > support/compatibility. What versions of Gradle/Avro/Java do you want to > > support for new plugin releases? Do you only publish a single variant, > or > > do you publish multiple variants to expand your version coverage? What > do > > you do when one of the dependencies makes a breaking change? > > > > Historically, my answer has been that I publish a single variant that > > supports the latest released version of each dependency, with best-effort > > compatibility with previous versions (and CI coverage to allow for > accurate > > documentation of what the supported ranges are). When a dependency > > releases a breaking change, I cut support for previous versions (and > > document the last plugin version that supported the previous version). > > > > I have plans for an approach that would allow for a single Gradle plugin > > release to support "all" Avro versions, and a prototype branch > > demonstrating the technique, but have been unable to put adequate time > > together to port the whole plugin over to that approach. At that point, > > the question would be simplified to what Avro versions and what Gradle > > versions are supported, separately, rather than the combination thereof. > > > > On Thu, Sep 8, 2022 at 12:32 PM Ryan Skraba <[email protected]> wrote: > > > > > Hello David! This is a very generous offer -- I think it's really > > > quite nice to consider donating it to the Apache Avro community, > > > especially since it looks like it's a well-appreciated feature and > > > you've put quite a bit of effort into it! > > > > > > I personally think this would be a welcome addition to the Avro > > > project. We've accepted code donations in the past, we usually > > > discuss it on the mailing list among devs and then call a vote (See > > > the Rust SDK[1]). > > > > > > I downloaded, compiled and tested the project in a matter of minutes, > > > which is really promising! We currently use Maven (of course) for all > > > of our Java code, but I don't see it being a blocker to introduce > > > Gradle to build a Gradle plugin. > > > > > > You mentioned not having as much time to dedicate to this, but you > > > probably have some useful insights! Are you looking for someone to > > > just take the existing repo as-is, and repackage/adapt it into the > > > existing Avro project, or would you have some time (even limited) to > > > help guide us into putting it in place? Is there anything we should > > > especially consider? > > > > > > All my best, Ryan > > > > > > [1]: https://lists.apache.org/thread/m3r4svytnn6do9tw0476nwttgtcp60qj > > > "Rust donation vote." > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 7, 2022 at 3:16 PM David M. Carr <[email protected]> > wrote: > > > > > > > > In case someone on the list is interested: > > > > https://github.com/davidmc24/gradle-avro-plugin/discussions/208 > > > > > > > > Alternatively, if the Apache Avro project itself is interested in > having > > > an > > > > official Gradle plugin, the source is freely available and already > Apache > > > > licensed. > > > > > > > > -- > > > > David M. Carr > > > > [email protected] > > > > > > > > > -- > > David M. Carr > > [email protected] >
