Worked like a charm. I used my derived groovyclassloader to create my own compile unit that overrides the default resolve visitor with my own resolve visitor that first resolves per my needs and then calls the default resolve visitor to close out every else.
Thank you for your response Regards On Mon, 19 Oct, 2020, 21:32 Milles, Eric (TR Technology), < eric.mil...@thomsonreuters.com> wrote: > You might run your transformation in (at least) 2 phases. In the first > phase, you can mark or replace ClassNode instances that you expect to fill > in as resolved or primary. ResolveVisitor checks isResolved() and > isPrimaryClassNode() first. > > -----Original Message----- > From: Saravanan Palanichamy <chava...@gmail.com> > Sent: Monday, October 19, 2020 5:53 AM > To: dev@groovy.apache.org > Subject: Dynamic class types > > Hello everyone > > My DSL that uses AST transformations has this quirk > * A Groovy script defines classes and uses other classes from the class > path > * I want to be able to replace all these types during compile with my own > standard class definition > * If I have the types I am replacing in the class path, everything works. > If I do not have them in the class path, then the resolvevisitor fails > trying to locate these classes. This is as expected. In my case though, I > have no use for these classes after the compile, I replace all of these > classes with a standard class definition and route all data and method > access through this standard class definition > > My question is this > * How can I create a place holder definition for these external classes so > things will load fine, giving me a chance to replace them with the standard > definition and cleanly tie up loose ends through an AST transformation? I > am looking for a mechanism similar to the type checking extensions, > essentially a type specifying extension that works in the semantic analysis > stage > > What I have tried so far > * I use a custom parent class loader that will return this standard > definition for any classes not found in the parent. But this did not work > because the class loading attempts to search through all standard package > paths and I end up seeing inner lookups, nested lookups and outer lookups > all of which should fail. > > Any help on how to proceed is super appreciated >
