groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mr Andersson <>
Subject Re: Is it possible to enable CompileStatic for an entire project
Date Tue, 21 Jun 2016 21:41:39 GMT

On 06/21/2016 10:55 PM, Jochen Theodorou wrote:
> [...]
>> 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". 
> 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..

yes, this was enough!

                                 <taskdef name="groovyc" 


>> *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.

Yes, great. Then one can @CompileDynamic on demand.


> bye Jochen

View raw message