MG, I might be wrong (haven't checked for a long long time and at least a couple of major Groovy versions), but I believe groovyc always simply re-creates all the .class files which result from a source compiled (could be a number of them: aside of the closure classes, groovyc — very reasonably unlike the Java disaster — supports any number of class definitions in one source, and can generate one more as a script if the source happens to have statements outside all classes).
(And yes, if your build system supports the incremental build, it can be a royal PITA. My scripts — so that I can build directly from Xcode, I wrote a set of my own ones — do support incremental and it doesn't work quite reliably due to this very problem. I considered to make a special support which would internally pair the source with all the classes generated from it, allowing the scripts later to check timestamps and auto-delete extra classes which are not needed anymore, yadda yadda, but, alas, so far I haven't got to implementing it properly — ars longa, vita brevis :/ ) All the best, OC > On 14. 1. 2024, at 20:02, MG <mg...@arscreat.com> wrote: > > Hi Jochen, > we build using IntelliJ, and this has occurred independent of the IntelliJ > version for years. > (It is now that I work more from home that this becomes more of a nuiscance, > due to much slower upload speed to the server.) > Does "Groovyc compiles what you give it to compile" hold true in this case ? > Closures are compiled to classes, but they do not exist as such in the code, > so how would IntelliJ tell Groovyc to compile (or not compile) the closures > in a Groovy source file... ? > Based on this I always assumed it is Groovyc who decides to recreate all > those auto-generated closure classes... (?) > Cheers, > mg > > > On 14/01/2024 14:04, Jochen Theodorou wrote: >> On 12.01.24 18:50, MG wrote: >>> Hi guys, >>> >>> is there a way to get Groovy not to nedlessly recreate closure class >>> files during a build which would otherwise just change one or two >>> non-closure class files ? >>> The recreation of large numbers of closure class files seems to be >>> triggered randomly at certain points, and having to continuously >>> rsync-upload these files to the server after small code changes becomes >>> a factor in turnaround time... >> >> I think we need a bit more detail. Groovyc compiles what you give it to >> compile. If something is deciding one time to compile a set A and >> sometimes a set B, then it is because the part controlling Groovyc >> decided to do that. >> >> so what is controlling Groovyc in your case? Gradle, Maven, Intellij..? >> >> bye Jochen >> >
