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
>
>

Reply via email to