Thank you Jochen, I made some progress based on your recommendations in this manner
1. Added one source file as source unit to the compilation unit 2. I use a compilation unit that uses my custom ClassNodeResolver that derives from the base ClassNodeResolver 3. When it hits the findClassNode function, I call the parent, if the parent returned null, I then look in my directory folder for the file (I use the node name, replace the .'s with /'s and look for the file in my source folders) 4. And it works beautifully as it goes through resolving things for me Right now I feel like the kitten that unravelled the dependency string ball.😃 , thank you very much for helping with this But I ran into one snag. If the ClassNodeResolver is looking for a class ABC.INNERDEF, then I am able to detect and resolve ABC and add that source unit to the compilation process. However, this causes an issue with the phased operations. This is my pseudo code // If a class node was not found > LookupResult MyClassNodeResolver.findClassNode(String name, > CompilationUnit compilationUnit) { > var parentResult = super.findClassNode(name, compilationUnit) > if (parentResult == null) findInMyRepository(name, compilationUnit) > } > > LookupResult findInMyRespository(name, ...) { > > // Find name or a substring of name in my folders (I search for > "." increments) > // If whole name or partial name found, return that result > var sourceUnit = new SourceUnit(fileFound, ...) > compilationUnit.addSource(sourceUnit) > return LookupResult(sourceUnit, null) > } The compile error is that a class gets left behind in the CompileUnit's classesToCompile. I think this is because I am returning a source unit that contains both outer and inner classes when the look up should have returned an inner class. What is the right way to fix this? Should I add the source unit but return a dummy classnode that is not resolved yet? regards Saravanan On Tue, Jun 10, 2025 at 8:59 AM Jochen Theodorou <blackd...@gmx.org> wrote: > On 10.06.25 15:15, Saravanan Palanichamy wrote: > [...] > > 1. Add ABC.java as the only source unit. Then I override resolve > > visitor, to detect all resolve attempts. I now know what other > > classes need to be resolved, so I try to add new files to the > > compilation units. The code looks like it should go back to > > initialization phase. Now when I see other classes that I added, I > > can repeat this process recursively. I am not sure how feasible this > > is given the amount of looping back and forth > > that is perfectly fine. > > > 2. Your comment about allowing groovy to find the script file was > > interesting. So run GroovyC on one file and let the compile find all > > dependencies as scripts. This looks like exactly what I want to do > > in 1. but all my files are named .java so I am not sure groovy will > > find them > > didn't we have an option to set the extension of the files in the > compiler configuration? > > > Which approach do you think I should try? > > the later one looks promising. Don't worry about resolving the same file > multiple times. Resolved types will stay resolved and skipped if the > resolver revisits them. Also not the whole compiler goes back to init, > just for the specific source unit. Once all source units are at the same > progress level they proceed together again. > > bye Jochen > >