David M. Carr

> I think the behavior I'd expect as a user is to explicitly say that the parent classloader is null. If you can't resolve the resource from the classpath of...

Yes, version 2.0 (if I ever finish it) will run the Avro logic in a separate JVM from the build. The main reason for that is to allow supporting arbitrary...

Yeah, using an older version might explain it. Let me know how the upgrade goes.

I believe that statement was with regards to standalone avsc files. The IDL supports import statements that hopefully addresses this need.

Short answer: it's complicated. This plugin is built around the [java library](https://github.com/apache/avro/tree/master/lang/java) published by the Avro project... which doesn't always provide the capabilities one would want when writing a Gradle...

I'll take a look at this more tonight and add an example project to the repo.

@nbuesing @philipp94831 I've added a couple additional examples [here](https://github.com/davidmc24/gradle-avro-plugin/tree/master/examples) that might be useful. * [avsc-from-external-jar](https://github.com/davidmc24/gradle-avro-plugin/tree/master/examples/avsc-from-external-jar): generating Java objects from a schema file that depends on schema files in an arbitrary...

Nice example. I've integrated it into the avsc-from-subproject example in the repository. Using `doFirst` on the jar task I was able to eliminate `it.dependsOn(task.classes)`. I can confirm that using zipTree...

As for whether it makes sense to include some of this by default in the Avro conventions plugin... maybe. I've gotten enough requests for ways to depend on external schema...

> I also used doFirst on the jar task at first but that also broke caching. Good point. Fixed that based on your pattern.