[...]
The problem with the ANT task is that I don't think I can set classpath
argumetns to the actual so passing the config location is a problem that
needs be resolved. Not that easy with maven.
I am actually not quite sure what you mean with "I don't think I can set
classpath arguments to the actual".
http://docs.groovy-lang.org/2.4.7/html/api/org/codehaus/groovy/ant/Groovyc.html
shows some usages in pure ant, that also define a classpath, plus the
config script is just another argument on the task... in your maven
versions you had <classpath refid="maven.compile.classpath"/>, so I
guess the classpath problem is a solved one? As I said, I don´t fully
understand what you mean..
*Groovy should instead provide a default GroovyStatic-2.4.4.jar* file
that enables this by default. That way everybody wins, and Groovy could
join the club of static languages and not get rejected by those that
needs to get Groovy.
>
It is also messy to set up config files for every maven module, although
I am not sure. The code in that config file is also not dynamic.
>
withConfig(configuration){ast(groovy.transform.CompileStatic)} and a
simple option -compileStatic that uses an internal version of that file
is preferable and *SIMPLER***.
groovyc -configscript src/conf/config.groovy src/main/groovy/MyClass.groovy
Is not needed here.
I think a command line option is something we can do. Those config
scripts are actually more powerful, in that you can freely configure the
compiler in them - better than any option would be able to do. Typical
use case is to define several transforms that are always applied.
CompileStatic is only one among them... ut it has a very distinct use
case, which is why we really should consider adding that as a standard
option.
bye Jochen
