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 <[email protected]> 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
>
>
