Hi Alexey, I managed to replicate using your code - thanks. But I didn't have time yet to see if I could come up with a way to implement your suggestion in a backward compatible way. Is there a Jira for the issue yet? Please create one if not.Cheers, Paul.On Tue, May 7, 2019 at 7:16 PM Alexey Belostotskiy <firstname.lastname@example.org> wrote:Hi,Did you get a chance to test it?26.02.2019, 00:24, "Paul King" <email@example.com>:Hi Alexey, the attachment came through. I just haven't had time to test it yet. Thanks!Cheers, Paul.On Tue, Feb 26, 2019 at 1:20 AM Alexey Belostotskiy <firstname.lastname@example.org> wrote:Hi, did you receive the last email (with test in attachment)? I'm not sure if it was sent properly.20.02.2019, 17:34, "Alexey Belostotskiy" <email@example.com>:Hi, it's kind of messy, but I hope you'll get the idea.19.02.2019, 23:48, "Paul King" <firstname.lastname@example.org>:Our preference would be to have a standalone testcase that triggers your problem. Are you in a position to create such a test?On Wed, Feb 20, 2019 at 1:24 AM Alexey Belostotskiy <email@example.com> wrote:Hello,We're generating groovydocs in runtime in our app. We use groovydoc as a library, not standalone tool.It mostly works, but we're experiencing issues with some classes ending up unresolved. I found out that this happens because SimpleGroovyClassDoc is calling its getClass().getClassLoader() to get classloader for class resolution. But in our case, most of classes that we want to link should be loaded via different classloader.Basically, solution that would work for us, is to replace getClass().getClassLoader() calls in SimpleGroovyClassDoc with Thread.currentThread().getContextClassLoader(), but that might be a breaking change.I'm not sure what the process is for requesting such changes and whether it's something that Groovy team is willing to implement.