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 <lexek...@ya.ru> wrote: > Hi, > Did you get a chance to test it? > > 26.02.2019, 00:24, "Paul King" <pa...@asert.com.au>: > > 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 <lexek...@ya.ru> > 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" <lexek...@ya.ru>: > > Hi, it's kind of messy, but I hope you'll get the idea. > > 19.02.2019, 23:48, "Paul King" <pa...@asert.com.au>: > > 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 <lexek...@ya.ru> > 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. > >
