Hello Ismael -- pertinent comments! It looks to me like a code drop is appropriate (making the appropriate changes to artifact, group ids, packages, etc). I think we could discuss functional changes with respect to versioning -- the current gradle-avro-plugin can generate MANY versions of Avro specific records. If each Avro release has a new release of the plugin, this might not be necessary. If you take a look at the plugin code itself, it's a pretty nicely laid out mapping from gradle configurations to SpecificCompiler configurations.
In the [VOTE] thread, Oscar mentioned that it is possible to build a gradle plugin with maven, but I really have no objection to using gradle to build gradle functionality alongside maven. This shouldn't be a blocker if the actual code is useful to the community, any more than using several JDKS. The gradle compatibility tests are *very* comprehensive, and make me wonder if we're not missing something important in doing the same with the maven plugin. Definitely to be taken into account, but also (in my opinion) doesn't make or break the donation potential! My sincere hope is that, by finding a home in the Apache project, we can draw the people that are using the plugin as contributors to its maintenance. I think we have a certain credibility in this area! All my best, Ryan On Mon, Oct 17, 2022 at 2:28 PM Ismaël Mejía <[email protected]> wrote: > > Hi, > > I want to add some comments here to not hijack the VOTE thread. > > I have mixed feelings about this. I like the idea of the Avro > community maintaining the plugin specially if it is going to go > unmantained, it can definitely grow because of it, but I am afraid of > two things: > > 1. Would it be just a code drop? > > Finding gradle experts is already scarcer than Maven ones, for example > the current Avro maven plugin is almost unmaintained. How can we > actively avoid this from happening? > > 2. What is the impact for Avro's build and testing infrastructure? > > Will this imply a second build system with its extra complexity as > part of the Avro release or can we do it with maven? > > Also, what is the impact at test time. I just quickly checked and just > the current gradle compatibility tests of the gradle plugin account > for 30 minutes (on Github Actions). We should probably stop supporting > so many gradle versions to keep the build times reasonable compared to > the user needs. > > Regards, > ismaël > > > > > > > > > On Mon, Oct 10, 2022 at 6:50 PM Ryan Skraba <[email protected]> wrote: > > > > Thanks for the info David and Michael (and welcome for your first post)! > > > > It's been a month and we've got a bit of guidance and info, let's just > > call the vote. I have to admit that I specifically went to a gradle > > talk at ApacheCon this year to learn a bit myself :D I'll send a > > message soon! > > > > Ryan > > > > > > > > On Fri, Sep 9, 2022 at 11:10 PM David M. Carr <[email protected]> wrote: > > > > > > I hadn't heard of avro-util before. That's interesting. I'm not > > > surprised > > > that LinkedIn was the source of something like that, though. They're one > > > of the larger users of the plugin, from what I hear through the grapevine. > > > > > > As for how often Gradle breaks compatibility... it depends on what you > > > consider a "break", and how willing you are to do workarounds. For > > > example, when they roll out a new feature that will improve build > > > performance, it often requires use of a new API which wasn't present in > > > previous versions. You can either not support it (in which case the > > > plugin > > > will usually work fine, as they pay a fair amount of attention to > > > backwards > > > compatibility), though after some number of versions the old way may be > > > deprecated and eventually removed. If you do support it, you might > > > consider using reflection to use the old/new API depending on the version, > > > especially for minor changes. > > > > > > I'm currently supporting Gradle 5.1 (released Jan 02, 2019) to 7.3 > > > (released Nov 09, 2021). I expect the most recent versions are also > > > compatible, but haven't updated the testing matrix recently. The last > > > time > > > I dropped support for older Gradle versions was in order to support Task > > > Configuration Avoidance; see > > > https://docs.gradle.org/current/userguide/task_configuration_avoidance.html. > > > > > > On Fri, Sep 9, 2022 at 1:34 PM Michael Kohout <[email protected]> wrote: > > > > > > > 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] > > > > > > > > > > > > > > > > > > -- > > > David M. Carr > > > [email protected]
