I'm definitely planning on contributing. On Thu, Oct 20, 2022, 12:13 PM Ryan Skraba <[email protected]> wrote:
> 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] >
