Add ability to use conversions and type factories residing outside of build classpath

[erdi]

This is needed for when the conversions and/or type factories that are being configured for use by the plugin are part of the same build and you end up with a chicken and egg problem forcing you to using trickery in buildSrc (this is actually exposed by existing tests in CustomConversionFunctionalSpec). Hopefully the test I added documents the use case and proves that the changes are working as intended.

I tried hard for this to be up to scratch. I did a basic compatibility check (thanks for making that easy, btw) which forced me to change my initial implementation slightly to account for Gradle 5.1. I will keep my eye on the pipeline and address any failures.

Please be informed that I will address any feedback within one business day at the most. I would really like to have this merged and released so I will gladly collaborate on making this happen.

I know this project is in maintenance mode, @davidmc24, so I'm sorry to be opening a PR but it already mostly does the job for us apart from the issue addressed by this PR so I'd rather contribute than reinvent the wheel.

[davidmc24]

Hey, @erdi, nice to hear from you. I'll take a look, and assuming I don't find any issues we can't work past, am fine with merging and releasing. Glad the plugin is helping people. :-)

[davidmc24]

Code changes look good.

Could you please take a pass at adding documentation of the new configuration options to the README.md, and a line to the unreleased changes section of CHANGES.md?

With this new approach, do you think that there are any of the previous configuration options that no longer make sense that should be deprecated or removed?

[davidmc24]

Based on the CI job, looks like some currently supported Gradle versions don't support injection of Project into extensions like you used.

https://github.com/davidmc24/gradle-avro-plugin/actions/runs/4608079685/jobs/8144604808?pr=228

FAILURE: Build failed with an exception. |  
  |   |  
  | * Where: |  
  | Build file '/tmp/spock_can_use_a_custom_co_0_testProjectDir3224446360342768687/build.gradle' line: 7 |  
  |   |  
  | * What went wrong: |  
  | A problem occurred evaluating root project 'spock_can_use_a_custom_co_0_testProjectDir3224446360342768687'. |  
  | > Failed to apply plugin [class 'com.github.davidmc24.gradle.plugin.avro.AvroBasePlugin'] |  
  | > Could not create an instance of type com.github.davidmc24.gradle.plugin.avro.DefaultAvroExtension. |  
  | > Unable to determine constructor argument #1: missing parameter of interface org.gradle.api.Project, or no service of type interface org.gradle.api.Project

<br class="Apple-interchange-newline">

Please consider if there are other options that would be compatible. If not, determine what the minimum Gradle version needed for this feature is, and I'm okay with updating the minimum supported version of Gradle.

[erdi]

Based on the CI job, looks like some currently supported Gradle versions don't support injection of Project into extensions like you used.

Should be fixed in 5ede65a, waiting for the CI job to confirm...

[erdi]

Could you please take a pass at adding documentation of the new configuration options to the README.md, and a line to the unreleased changes section of CHANGES.md?

Addressed in 09fafb2

With this new approach, do you think that there are any of the previous configuration options that no longer make sense that should be deprecated or removed?

While everything that could be previously achieved with com.github.davidmc24.gradle.plugin.avro.AvroExtension#getLogicalTypeFactories and com.github.davidmc24.gradle.plugin.avro.AvroExtension#getCustomConversions can be also achieved with the newly added properties I wouldn't remove them as that would be backwards incompatible. I will add some deprecation notices, though.

[davidmc24]

Changes so far look good. Just the deprecation notice and a clean CI run and I'll be ready to merge.

[erdi]

Changes so far look good. Just the deprecation notice and a clean CI run and I'll be ready to merge.

Deprecations added in b4ac5ba. All comments addressed, over to you.

[davidmc24]

@erdi Thanks! I'll review the CI results, and unless something new comes up, will merge and hopefully do a release sometime this evening.

[erdi]

CI looks green. 🎉

Fingers crossed nothing new comes up and you will find a while to do the release. Thanks for prompt reviews!

[davidmc24]

Included in release 1.7.0 and published to Maven Central. There may be some delay before it becomes visible there.

https://github.com/davidmc24/gradle-avro-plugin/actions/runs/4620107604/jobs/8169751045

[erdi]

Awesome, thank you very, very much!

[erdi]

FWIW, I've integrated these changes into the project I'm using the plugin on and everything works as expected. 🎉

[anilkulkarni87]

@erdi Would you be able to share an example project. I have been trying hard to make this work but not successful.

[erdi]

For an example project I'd suggest you check out the test I added as part of this PR, @anilkulkarni87. I'd debug the test, put a breakpoint at https://github.com/davidmc24/gradle-avro-plugin/pull/228/files#diff-b6d697ce9c603d8ed2be90b0987c81490d2bc8d30c8759a33906af5e492558f4R207, evaluate testProjectDir to check where it points at and the see the files within that directory.

[anilkulkarni87]

@erdi Thank you for the response. But i was able to make it work.
Here is my example project

https://github.com/anilkulkarni87/AvroJnaana/blob/main/schemas/build.gradle

This made life so much easier for me.

[erdi]

I’m glad to hear that this is beneficial to more people than just myself, @anilkulkarni87.