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
