On 06/21/2016 11:41 PM, Mr Andersson wrote:
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".
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..
yes, this was enough!
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-antrun-plugin</artifactId>
<version>1.8</version>
<executions>
<execution>
<id>groovyc-compile</id>
<phase>compile</phase>
<configuration>
<target>
<taskdef name="groovyc"
classname="org.codehaus.groovy.ant.Groovyc">
<classpath
refid="maven.compile.classpath"/>
</taskdef>
</target>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
I take this back, it compiled fine but no classes were actually included
in the war/jars.
*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.
I
bye Jochen
