groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject groovy parsers as subprojecs
Date Thu, 17 Nov 2016 19:00:55 GMT
Hi all,

now, after trying several variants I'd like to explain some of my 
results. My goal was trying to make the antlr2 parser a sub project. The 
biggest hurdle here is the AntlrParserPlugin, which references about all 
ast classes, ClassNodeHelper being used by AST classes and at the same 
time referencing classes like Closure, Closure and others referencing 
meta class internals... well.. that means there is no real separation od 
compiler, library and runtime.

So here variants I tried:
I) let main not depend on the parser sub project, but let it add its 
source paths to main, effectively making that more like a source 
extension, than a module.

This variant works and is for example used by the antlr4 parser

II) make a real parser subproject and let root:compileGroovy depend on 
it while the subproject's compile Java depends on root:compileJava

This variant I could not make work... even trying to forcefully break up 
the circular dependencies did not work in the end... I spend much too 
much time on this one and the groovy plugin gets in the way all the time

III) make the subproject an independent build and use Gradle's new 
composite build to realize that.

This variant works, but it means we compile the parser plugin against an 
older version of Groovy. If we make incompatible changes or add 
something new to the AST the parser is supposed to use, we would first 
have to prepare the AST, then release and after that we can finally use 
it. It means even a small new feature will take ages to get in. I guess 
that is no solution then.

So in total (I) seems like the best choice unless we manage to not let 
the AST classes reference Groovy classes from groovy.lang and choose 
(II). But considering something like scripts extending the compiler... 
not sure that is even possible to really achieve.

bye Jochen

View raw message