Re: Is it possible to enable CompileStatic for an entire project

[Mr Andersson]

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 , 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!


org.apache.maven.plugins
maven-antrun-plugin
1.8


groovyc-compile
compile


classname="org.codehaus.groovy.ant.Groovyc">
refid="maven.compile.classpath"/>






run







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

Re: Is it possible to enable CompileStatic for an entire project

[Keegan Witt]

Besides the example page, I have an integration test (
https://github.com/groovy/GMavenPlus/tree/master/src/it/configScriptCompile)
making sure this functionality works.  If you'd like, I'm willing to help
with your pom.

-Keegan

On Tue, Jun 21, 2016 at 12:37 PM, Mr Andersson 
wrote:

>
>
> On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:
>
> Tying Cédric’s advice to your previous question about gmavenplus and joint
> compilation, per
> https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script
> you add the configuration tag with a reference to your groovy script.
>
> I also mentioned that I could not get Gmavenplus to work, but maybe i did
> something wrong. But I literally copied and pasted that section.
>
>
>
> Actually about 90+% of our code base in Groovy is CompileStatic I wonder
> if we should use that. Cédric, if we use the config script method, is it
> still possible to use the “skip” annotation to switch back to dynamic mode?
> Even if it worked, I highly doubt IntelliJ IDEA would know about it and
> think all files are dynamic typing so probably it’s still best for us to
> add @CompileStatic everywhere, but sometimes we forget where we wanted it.
> The performance difference is extreme when we forget it, on a certain class
> we missed recently it took our page rendering times from about 4ms to 52ms,
> so for us it’s an actual “bug” to forget to add @CompileStatic.
>
>
> 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.
>
> *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.
>
>
>
>
> Jason
>
>
>
> *From:* Cédric Champeau [mailto:cedric.champ...@gmail.com
> ]
> *Sent:* Tuesday, June 21, 2016 8:29 AM
> *To:* users@groovy.apache.org
> *Subject:* Re: Is it possible to enable CompileStatic for an entire
> project
>
>
>
> It's in the docs:
> 
> http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
>
>
>
> 2016-06-21 14:24 GMT+02:00 Mr Andersson :
>
> Is it possible to enable CompileStatic for an entire project?
>
> Or do you have to do it on a per class basis?
>
> I like Groovy for some of it's features, and mostly for it's close to Java
> syntax but I would really like it to be a static language.
>
> I've heard about Groovy++ but I believe that's dead by now, no?
>
> Question is wether you can tell the Groovy compiler with a flag to treat
> all Groovy classes on certain paths as static?
>
> Preferable doable from ANT too.
>
>
> --
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>
>
>

Re: Is it possible to enable CompileStatic for an entire project

[Mr Andersson]

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 , 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!


org.apache.maven.plugins
maven-antrun-plugin
1.8


groovyc-compile
compile


classname="org.codehaus.groovy.ant.Groovyc">
refid="maven.compile.classpath"/>






run








*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

Re: Integrating Groovy with a Java EE application and Maven

[Mr Andersson]

On 06/21/2016 10:39 PM, Jochen Theodorou wrote:

On 21.06.2016 09:04, Mr Andersson wrote:

Gmaven or Gmaven 2 did not work for me either. Resulted in a bunch of
compilation issues which I started to correct, but then gave up on. I
shouldn't have to change my code to get on Groovy.


yeah, forget about those... gmavenplus is supposed to work. If that 
one does not do the job, then there is a problem


[...]

Plus have you seen the size of this examples page?

https://github.com/groovy/GMavenPlus/wiki/Examples

Fifty ways to configure. I don't even know anything about what I need
when i start off, so that's just too much headache.


you wanted joint compilation, so go to 
https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation 
and hopefully be done.


Did not work :(




The ant task for me is good enough.


well, then everything is almost fine ;)

[...]

command line is even more simple ;)


Not easy to integrate a command line argument for maven it seems. I am
not sure how you can add that to the classpath. I was trying really hard
on that but could not find any info, like with everything involving
searching for Java issues. Google sucks at this, or the Java folks
seriously do not ask or think enough about doing things the right way.

https://www.google.pl/search?q=adding+to+maven+classpath&oq=adding+to+maven+classpath&aqs=chrome..69i57j0l5.10311j0j7&sourceid=chrome&es_sm=93&ie=UTF-8 





Yes, you are right.


org.apache.maven.plugins
maven-antrun-plugin
1.8


groovyc-compile
compile









run



This seems to be enough and built successfully. Great! Even 
simpler! If only I could pass a compilesStatic flag too. But I guess I 
could put the classpath to a global config file for now. But Groovy 
should consider adding such a flag alternatively provide a jar that has 
this option turned on. It will bring back Groovy++ and that's defintely 
desirable. I love Groovy and it's closeness to the java syntax and it's 
much better interop with Java and have been resisting a switch to Scala 
and Kotlin because you have to use ugly syntax to access from Java their 
logic. With Groovy it is basically Java. Groovy adds so much to Java and 
should really have an option to go static.


I think the maven structure is not really made for executing command 
line commands... you could always use the ant runner to do that kind 
of thing of course, but then why use maven at all.
In constract, pulling in Scala and Kotlin ( during the process 
which I gave up on Groovy ) took seconds. 
well, there are some maven people, here only very few 
Groovy has been alive for over 10 years. It has to be a couple of 
people wanting to integrate Groovy in a JEE environment by now. 
maven works best if you follow the maven conventions and the very few 
maven projects I had to do with really tried to follow that.
And I doubting the procedure is different for gradle. 
give it a try. But it has its quirks too as well of course. For 
example if you have files in src/main/java and in src/main/groovy, the 
groovy plugin will not do joint compilation for the files in 
src/main/java. You can easily change that by 
sourceSets.main.java.srcDirs = [] sourceSets.main.groovy.srcDirs += 
["src/main/java"] or use a totally different folder or multiple 
folders. ant is more direct in that you will always have to supply 
that information anyway. if that is more easy or not, I don´t know. 
But I have seen some pretty complex builds and most of them I really 
would not like to do with ant I must say.
Relying on the Eclipse compiler is not a good thing as it has a 
history of breaking and not being up to date with any other 
compiler that one might wish to use. 
Which is why the page suggests gmavenplus for maven... maybe that 
should be more clear 
Did not work with both. The ant task should be the one mentioned 
because it will always succeed, unless you can figure how to add it 
to the classpath. 
Most important is that you got something working. Granted, it took too 
long and longer than it should have, and that is the fault of our 
documentation. Which brings me to the point of asking you what you 
would suggest how we should change our documentation so the next one 
will not have to do so much fighting. 
Add the ant option at the top. Gmavenplus did not work for me when I 
tried the join compilation option.

[...]
I am not sure what it means that you always compile all files. I 
haven't tried it enough but besides a 15 seconds extra build time, i 
don't see much difference in repetition. 
It means, that if you change one class, you will compile all of them 
and live with the build overhead. If you have several hundred files to 
compile, this will add up during development and testing. 
For intellij this doesn't seem 

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

I can say as someone who writes Groovy on a daily basis for about a year now on 
a project that uses CompileStatic by default on a team of 6-10 that we haven’t 
had many problems forgetting @CompileStatic or been too annoyed with it. 
Although as I’ve said in earlier post, we have forgotten once or twice and that 
did have a substantial impact. In your IDE you can even create a file template 
for Groovy class to add @CompileStatic for you. It’s not bad and IDE support 
follows. Therefore, I would say current Groovy support is good enough for those 
looking for a static language. For us using something like compiler 
configuration would just confuse things, especially since it is likely 
invisible to IDE.

Jason

From: Mr Andersson [mailto:mr.andersson@gmail.com]
Sent: Tuesday, June 21, 2016 5:31 PM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project


On 06/21/2016 08:08 PM, Winnebeck, Jason wrote:
I would say that if you use the config script, then it would mean you’d want to 
use @CompileDynamic on every class where you don’t want static. It’s a default. 
I would think once you start adding logic into a compiler config script like 
that you’ll get into trouble with users being confused.

I’m going to say something a little radical: if you want to use static 
compilation all the time, you may want to consider Kotlin, which is 1.0 now and 
similar to Groovy but is static compiled all the time. No offense to Jochen and 
other’s amazing work that I think brought new life to Groovy (I’d probably not 
be using it all were it not for CompileStatic), I’ve encountered a handful of 
compiler bugs unfortunately and still do from time to time, enough that I’ve 
learned how to read Java bytecode. I still like the language features of Groovy 
better and I haven’t found any solution other than dynamic Groovy to reasonably 
process web services/documents though, so I still like Groovy better until it’s 
possible to combine Kotlin+Groovy or Kotlin adds dynamic features. If you do 
use Groovy static compile then make sure definitely to go with the latest 2.4.7.

Exactly my point. I do not want to switch to Kotlin or Scala because you would 
have to learn a new language. Groovy's power is that it is so similar to Java 
"yet as powerful".

If groovy were to make a compilestatic jar file, then it will be more 
attractive to many requiring and liking a statically typed language.

This is the weakest point of groovy right now, and it would win the last 
argument and become a choice for those choosing a statically typed JVM 
language, yet can go into dynamic mode on demand.


Jason

From: Mario Garcia [mailto:mario.g...@gmail.com]
Sent: Tuesday, June 21, 2016 1:03 PM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

If I'm not wrong, projects like Spock doesn't like @CompileStatic so in case I 
would like to statically compile my project, at least I should be telling the 
compiler not to compile statically my specifications. Something like:

withConfig(configuration) {
source(unitValidator: { unit -> !unit.AST.classes.any { 
it.name.endsWith('Spec') } }) {
ast(CompileStatic)
}
}

my two cents
Mario

2016-06-21 18:44 GMT+02:00 Cédric Champeau 
mailto:cedric.champ...@gmail.com>>:
A strong -1 for both options. We already have 2 variants of Groovy today, indy 
and non indy, and in practice *nobody uses the invokedynamic version* because 
it's impractical to use. Typically projects depend on `groovy.jar` or 
`groovy-all.jar`, not their invokedynamic version. Adding a new dimension, 
which is orthogonal to invokedynamic makes it even more complicated. Don't 
forget that the Groovy compiler is also mixed in its runtime (which is a 
problem of its own). We should solve that first.

Second, IDEs need to know whether a file is statically compiled or not. The 
`@CompileStatic` annotation makes it very clear, and the default is the 
standard dynamic mode that has been in Groovy for more than 10 years. IDEs know 
about it, and it's simple to infer. Any alternative solution, like the config 
script, or an alternate compiler (!) makes it impossible for the IDE to guess. 
The only IDE-pragmatic solution is to have a distinct file extension for 
statically compiled Groovy files (say, .sgroovy instead of .groovy). So far 
this has been ruled out, but I think it's the most pragmatic, and IDE friendly, 
solution.



2016-06-21 18:37 GMT+02:00 Mr Andersson 
mailto:mr.andersson@gmail.com>>:

On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:
Tying Cédric’s advice to your previous question about gmavenplus and joint 
compilation, per 
https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you add 
the configuration tag with a reference to your groovy script.
I also mentioned that I could not get Gmavenplus to work, but maybe i did 
something wrong. But I literally copied and paste

Re: Is it possible to enable CompileStatic for an entire project

[Mr Andersson]

On 06/21/2016 08:08 PM, Winnebeck, Jason wrote:


I would say that if you use the config script, then it would mean 
you’d want to use @CompileDynamic on every class where you don’t want 
static. It’s a default. I would think once you start adding logic into 
a compiler config script like that you’ll get into trouble with users 
being confused.


I’m going to say something a little radical: if you want to use static 
compilation all the time, you may want to consider Kotlin, which is 
1.0 now and similar to Groovy but is static compiled all the time. No 
offense to Jochen and other’s amazing work that I think brought new 
life to Groovy (I’d probably not be using it all were it not for 
CompileStatic), I’ve encountered a handful of compiler bugs 
unfortunately and still do from time to time, enough that I’ve learned 
how to read Java bytecode. I still like the language features of 
Groovy better and I haven’t found any solution other than dynamic 
Groovy to reasonably process web services/documents though, so I still 
like Groovy better until it’s possible to combine Kotlin+Groovy or 
Kotlin adds dynamic features. If you do use Groovy static compile then 
make sure definitely to go with the latest 2.4.7.




Exactly my point. I do not want to switch to Kotlin or Scala because you 
would have to learn a new language. Groovy's power is that it is so 
similar to Java "yet as powerful".


If groovy were to make a compilestatic jar file, then it will be more 
attractive to many requiring and liking a statically typed language.


This is the weakest point of groovy right now, and it would win the last 
argument and become a choice for those choosing a statically typed JVM 
language, yet can go into dynamic mode on demand.


Jason

*From:*Mario Garcia [mailto:mario.g...@gmail.com]
*Sent:* Tuesday, June 21, 2016 1:03 PM
*To:* users@groovy.apache.org
*Subject:* Re: Is it possible to enable CompileStatic for an entire 
project


If I'm not wrong, projects like Spock doesn't like @CompileStatic so 
in case I would like to statically compile my project, at least I 
should be telling the compiler not to compile statically my 
specifications. Something like:


withConfig(configuration) {

source(unitValidator: { unit -> !unit.AST.classes.any { 
it.name.endsWith('Spec') } }) {


ast(CompileStatic)

}

}

my two cents

Mario

2016-06-21 18:44 GMT+02:00 Cédric Champeau >:


A strong -1 for both options. We already have 2 variants of Groovy
today, indy and non indy, and in practice *nobody uses the
invokedynamic version* because it's impractical to use. Typically
projects depend on `groovy.jar` or `groovy-all.jar`, not their
invokedynamic version. Adding a new dimension, which is orthogonal
to invokedynamic makes it even more complicated. Don't forget that
the Groovy compiler is also mixed in its runtime (which is a
problem of its own). We should solve that first.

Second, IDEs need to know whether a file is statically compiled or
not. The `@CompileStatic` annotation makes it very clear, and the
default is the standard dynamic mode that has been in Groovy for
more than 10 years. IDEs know about it, and it's simple to infer.
Any alternative solution, like the config script, or an alternate
compiler (!) makes it impossible for the IDE to guess. The only
IDE-pragmatic solution is to have a distinct file extension for
statically compiled Groovy files (say, .sgroovy instead of
.groovy). So far this has been ruled out, but I think it's the
most pragmatic, and IDE friendly, solution.

2016-06-21 18:37 GMT+02:00 Mr Andersson
mailto:mr.andersson@gmail.com>>:

On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:

Tying Cédric’s advice to your previous question about
gmavenplus and joint compilation, per

https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script
you add the configuration tag with a reference to your
groovy script.

I also mentioned that I could not get Gmavenplus to work, but
maybe i did something wrong. But I literally copied and pasted
that section.

Actually about 90+% of our code base in Groovy is
CompileStatic I wonder if we should use that. Cédric, if
we use the config script method, is it still possible to
use the “skip” annotation to switch back to dynamic mode?
Even if it worked, I highly doubt IntelliJ IDEA would know
about it and think all files are dynamic typing so
probably it’s still best for us to add @CompileStatic
everywhere, but sometimes we forget where we wanted it.
The performance difference is extreme when we forget it,
on a certain class we missed recently it took our page
rendering times from about 4ms to 52ms, so for us it’s an
  

Re: Is it possible to enable CompileStatic for an entire project

[Jochen Theodorou]

[...]

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 , 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

Re: Integrating Groovy with a Java EE application and Maven

[Jochen Theodorou]

On 21.06.2016 09:04, Mr Andersson wrote:

Gmaven or Gmaven 2 did not work for me either. Resulted in a bunch of
compilation issues which I started to correct, but then gave up on. I
shouldn't have to change my code to get on Groovy.


yeah, forget about those... gmavenplus is supposed to work. If that one 
does not do the job, then there is a problem


[...]

Plus have you seen the size of this examples page?

https://github.com/groovy/GMavenPlus/wiki/Examples

Fifty ways to configure. I don't even know anything about what I need
when i start off, so that's just too much headache.


you wanted joint compilation, so go to 
https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation and 
hopefully be done.



The ant task for me is good enough.


well, then everything is almost fine ;)

[...]

command line is even more simple ;)


Not easy to integrate a command line argument for maven it seems. I am
not sure how you can add that to the classpath. I was trying really hard
on that but could not find any info, like with everything involving
searching for Java issues. Google sucks at this, or the Java folks
seriously do not ask or think enough about doing things the right way.

https://www.google.pl/search?q=adding+to+maven+classpath&oq=adding+to+maven+classpath&aqs=chrome..69i57j0l5.10311j0j7&sourceid=chrome&es_sm=93&ie=UTF-8


I think the maven structure is not really made for executing command 
line commands... you could always use the ant runner to do that kind of 
thing of course, but then why use maven at all.



In constract, pulling in Scala and Kotlin ( during the process which I
gave up on Groovy ) took seconds.


well, there are some maven people, here only very few


Groovy has been alive for over 10 years. It has to be a couple of people
wanting to integrate Groovy in a JEE environment by now.


maven works best if you follow the maven conventions and the very few 
maven projects I had to do with really tried to follow that.



And I doubting the procedure is different for gradle.


give it a try. But it has its quirks too as well of course. For example 
if you have files in src/main/java and in src/main/groovy, the groovy 
plugin will not do joint compilation for the files in src/main/java. You 
can easily change that by


sourceSets.main.java.srcDirs = []
sourceSets.main.groovy.srcDirs += ["src/main/java"]

or use a totally different folder or multiple folders. ant is more 
direct in that you will always have to supply that information anyway. 
if that is more easy or not, I don´t know. But I have seen some pretty 
complex builds and most of them I really would not like to do with ant I 
must say.



Relying on the Eclipse compiler is not a good thing as it has a history
of breaking and not being up to date with any other compiler that one
might wish to use.


Which is why the page suggests gmavenplus for maven... maybe that
should be more clear


Did not work with both. The ant task should be the one mentioned because
it will always succeed, unless you can figure how to add it to the
classpath.


Most important is that you got something working. Granted, it took too 
long and longer than it should have, and that is the fault of our 
documentation. Which brings me to the point of asking you what you would 
suggest how we should change our documentation so the next one will not 
have to do so much fighting.


[...]

I am not sure what it means that you always compile all files. I haven't
tried it enough but besides a 15 seconds extra build time, i don't see
much difference in repetition.


It means, that if you change one class, you will compile all of them and 
live with the build overhead. If you have several hundred files to 
compile, this will add up during development and testing.



compared with eclipse groovy plugin:
* stubs cannot compile as many scenarios as the integrated approach of
the eclipse groovy compiler
* not really integrated in maven, thus you always compile all files

I am working on a new compiler tool for Groovy, which is supposed to
have less of those disadvantages, for which I will then also look for
more proper maven integration (I am hoping here on the help of gmaven
plus). But that is still in the future and no fast project, because my
free time is limited



It should be simple, one plugin declaration with all configuration right
there, and work.


agreed.. though will only if you follow the conventions for maven, 
because any different way will require additional configuration.. but I 
guess that is clear already


bye Jochen

Re: Groovy hot deploy in production

[Erwin Müller]

Just have a data storage for persistent data, and let the Groovy code access
that data in an atomic way.
Just a simple synchronized map would be sufficient as the data storage.
That way, you won't need to storage any data in your Groovy code.
It's just important to use atomic types like primitive types (int, float) or
AtomicInt, AtomicBoolean, and read-only types, like String, InetAddress,
joda.DateTime.
Later in the development you can exchange the simple synchronized map with
MemotyDb if you want to.  

For example,  

class DataStorage {
    private Map storage;
    DataStorage() {
    this.storage=Collections.synchronizedMap(new HashMap());
    }
    public void addUser(name);
    public void setUserPassword(name, password);
    public String getUserPassword(name);
    public void setUserTCP(name, tcp);
    public String getUserTCP(name);
    public void setUserUDP(name, udp);
    public String getUserUDP(name);
}  
>  Tue Jun 21 2016 20:01:42 CEST from "Aplomb Chen"  
>Subject: Re: Groovy hot deploy in production
>
>  I am developing chat servers which need hold user information in
>server memory like the tcp or udp channels and other user session data. 
>
>   
>
>  Hot deployments will be useful that I can keep the user information in
>memory and upgrade the business code for new features. So that those chat
>users won't need re-login again, otherwise I need restart chat servers for
>the upgrade which will easily cause login storm.
>
>   
>
>  Currently my plan is using groovy for hot deploy, I will do switching
>GroovyClassLoader every time when I need upgrade code, which means in groovy
>code, I can not hold any memory, I think the advantage is I can control to
>upgrade groovy scripts after the code is updated on server and demand our
>developers not hold any memory in groovy scripts, this is like how PHP does,
>right?
>
>   
>
>  For further thinking, to resolve the NOT hold any memory demand, I am
>thinking about implement MemoryDB (May like Redis, but much more simpler) for
>groovy scripts, so that developers can save objects to MemoryDB in runtime. 
>
>   
>
>  Do you think this is a reasonable design? Please advice, much
>appreciated! 
>
>  
>
>  
>  On Tue, Jun 21, 2016 at 11:54 PM, Domingo Suárez Torres
> wrote:
>  
>>  I always avoid hot deployments, I prefer to have multiple running JVMs
>>and a proxy or load balancer in front.   
>>
>>   
>>
>>  
>>
>>
>>On Tue, Jun 21, 2016 at 9:18 AM Erwin Müller
>> wrote:
>>
>>  
>>>
>>>
>>>Why not have start and stop hooks for such stuff?  
>>>
>>>Have an interface with onStart() and onStop() methods, and call them when
>>>you load and unload a class.  
>>>
>>>If you really need modularity, use OSGi.  
>>>
>>>Regards, Erwin.  
  Sun Jun 19 2016 15:00:56 CEST from "Aplomb Chen"
  Subject: Groovy hot deploy in production

  

>>>  
>>>
>>>
  

Hi Guys,   

   

Will you use groovy hot deploy in production environment? Is it reliable
to do so?  

   

I am worried that it may have issue when you are doing below,   

1, Defined a Array as class attribute, make it has 1 objects, next
time code hot deploy that the array is erased in code, then that must be an
memory leak, right?  

2, If you execute a periodic timertask in a groovy, next time code hot
deployed, if the timetask is no longer needed from your code, but the 
started
timertask will still be running, right?  

   

If we demands developers avoid using class attributes or starting any
thread thing as a development rule, will hot deploy still be good for
production?  

   

Aplomb  

   

Best regards  

  



  

>>>  
>>>
>>>
>>>
>>>   
>>>
>>>-- 
>>>Erwin Müller - erwin.muel...@deventm.org
>>>Software Entwickler - (+49) 01577-9505569
>>>Pgp - https://pgp.mit.edu/pks/lookup?op=get&search=0x02E820911DD910FD
>>>Meine Seite - http://www.mueller-public.de/
>>>ANRI - http://www.anr-institute.com/  
>>>
>>>  

>>  
>>
>>  
>>
>>  
>>
>>  

>  
>
>  
>
>  
>
>
>
>  

  


   

-- 
Erwin Müller - erwin.muel...@deventm.org
Software Entwickler - (+49) 01577-9505569
Pgp - https://pgp.mit.edu/pks/lookup?op=get&search=0x02E820911DD910FD
Meine Seite - http://www.mueller-public.de/
ANRI - http://www.anr-institute.com/

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

I would say that if you use the config script, then it would mean you’d want to 
use @CompileDynamic on every class where you don’t want static. It’s a default. 
I would think once you start adding logic into a compiler config script like 
that you’ll get into trouble with users being confused.

I’m going to say something a little radical: if you want to use static 
compilation all the time, you may want to consider Kotlin, which is 1.0 now and 
similar to Groovy but is static compiled all the time. No offense to Jochen and 
other’s amazing work that I think brought new life to Groovy (I’d probably not 
be using it all were it not for CompileStatic), I’ve encountered a handful of 
compiler bugs unfortunately and still do from time to time, enough that I’ve 
learned how to read Java bytecode. I still like the language features of Groovy 
better and I haven’t found any solution other than dynamic Groovy to reasonably 
process web services/documents though, so I still like Groovy better until it’s 
possible to combine Kotlin+Groovy or Kotlin adds dynamic features. If you do 
use Groovy static compile then make sure definitely to go with the latest 2.4.7.

Jason

From: Mario Garcia [mailto:mario.g...@gmail.com]
Sent: Tuesday, June 21, 2016 1:03 PM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

If I'm not wrong, projects like Spock doesn't like @CompileStatic so in case I 
would like to statically compile my project, at least I should be telling the 
compiler not to compile statically my specifications. Something like:

withConfig(configuration) {
source(unitValidator: { unit -> !unit.AST.classes.any { 
it.name.endsWith('Spec') } }) {
ast(CompileStatic)
}
}

my two cents
Mario

2016-06-21 18:44 GMT+02:00 Cédric Champeau 
mailto:cedric.champ...@gmail.com>>:
A strong -1 for both options. We already have 2 variants of Groovy today, indy 
and non indy, and in practice *nobody uses the invokedynamic version* because 
it's impractical to use. Typically projects depend on `groovy.jar` or 
`groovy-all.jar`, not their invokedynamic version. Adding a new dimension, 
which is orthogonal to invokedynamic makes it even more complicated. Don't 
forget that the Groovy compiler is also mixed in its runtime (which is a 
problem of its own). We should solve that first.

Second, IDEs need to know whether a file is statically compiled or not. The 
`@CompileStatic` annotation makes it very clear, and the default is the 
standard dynamic mode that has been in Groovy for more than 10 years. IDEs know 
about it, and it's simple to infer. Any alternative solution, like the config 
script, or an alternate compiler (!) makes it impossible for the IDE to guess. 
The only IDE-pragmatic solution is to have a distinct file extension for 
statically compiled Groovy files (say, .sgroovy instead of .groovy). So far 
this has been ruled out, but I think it's the most pragmatic, and IDE friendly, 
solution.



2016-06-21 18:37 GMT+02:00 Mr Andersson 
mailto:mr.andersson@gmail.com>>:

On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:
Tying Cédric’s advice to your previous question about gmavenplus and joint 
compilation, per 
https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you add 
the configuration tag with a reference to your groovy script.
I also mentioned that I could not get Gmavenplus to work, but maybe i did 
something wrong. But I literally copied and pasted that section.


Actually about 90+% of our code base in Groovy is CompileStatic I wonder if we 
should use that. Cédric, if we use the config script method, is it still 
possible to use the “skip” annotation to switch back to dynamic mode? Even if 
it worked, I highly doubt IntelliJ IDEA would know about it and think all files 
are dynamic typing so probably it’s still best for us to add @CompileStatic 
everywhere, but sometimes we forget where we wanted it. The performance 
difference is extreme when we forget it, on a certain class we missed recently 
it took our page rendering times from about 4ms to 52ms, so for us it’s an 
actual “bug” to forget to add @CompileStatic.

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.

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 

Re: Groovy hot deploy in production

[Aplomb Chen]

I am developing chat servers which need hold user information in server
memory like the tcp or udp channels and other user session data.

Hot deployments will be useful that I can keep the user information in
memory and upgrade the business code for new features. So that those chat
users won't need re-login again, otherwise I need restart chat servers for
the upgrade which will easily cause login storm.

Currently my plan is using groovy for hot deploy, I will do switching
GroovyClassLoader every time when I need upgrade code, which means in
groovy code, I can not hold any memory, I think the advantage is I can
control to upgrade groovy scripts after the code is updated on server and
demand our developers not hold any memory in groovy scripts, this is like
how PHP does, right?

For further thinking, to resolve the NOT hold any memory demand, I am
thinking about implement MemoryDB (May like Redis, but much more simpler)
for groovy scripts, so that developers can save objects to MemoryDB in
runtime.

Do you think this is a reasonable design? Please advice, much appreciated!

On Tue, Jun 21, 2016 at 11:54 PM, Domingo Suárez Torres <
domingo.sua...@gmail.com> wrote:

> I always avoid hot deployments, I prefer to have multiple running JVMs and
> a proxy or load balancer in front.
>
>
>
> On Tue, Jun 21, 2016 at 9:18 AM Erwin Müller 
> wrote:
>
>> Why not have start and stop hooks for such stuff?
>>
>> Have an interface with onStart() and onStop() methods, and call them when
>> you load and unload a class.
>>
>> If you really need modularity, use OSGi.
>>
>> Regards, Erwin.
>>
>> Sun Jun 19 2016 15:00:56 CEST from "Aplomb Chen"  
>> Subject:
>> Groovy hot deploy in production
>>
>> Hi Guys,
>>
>>
>>
>> Will you use groovy hot deploy in production environment? Is it reliable
>> to do so?
>>
>>
>>
>> I am worried that it may have issue when you are doing below,
>>
>> 1, Defined a Array as class attribute, make it has 1 objects, next
>> time code hot deploy that the array is erased in code, then that must be an
>> memory leak, right?
>>
>> 2, If you execute a periodic timertask in a groovy, next time code hot
>> deployed, if the timetask is no longer needed from your code, but the
>> started timertask will still be running, right?
>>
>>
>>
>> If we demands developers avoid using class attributes or starting any
>> thread thing as a development rule, will hot deploy still be good for
>> production?
>>
>>
>>
>> Aplomb
>>
>>
>>
>> Best regards
>>
>>
>>
>> --
>> Erwin Müller - erwin.muel...@deventm.org
>> Software Entwickler - (+49) 01577-9505569
>> Pgp - https://pgp.mit.edu/pks/lookup?op=get&search=0x02E820911DD910FD
>> Meine Seite - http://www.mueller-public.de/
>> ANRI - http://www.anr-institute.com/
>>
>

Re: Groovy hot deploy in production

[Aplomb Chen]

Thanks, onStart and onStop are a good hit for my cases.

On Tue, Jun 21, 2016 at 10:17 PM, Erwin Müller 
wrote:

> Why not have start and stop hooks for such stuff?
>
> Have an interface with onStart() and onStop() methods, and call them when
> you load and unload a class.
>
> If you really need modularity, use OSGi.
>
> Regards, Erwin.
>
> Sun Jun 19 2016 15:00:56 CEST from "Aplomb Chen"  
> Subject:
> Groovy hot deploy in production
>
> Hi Guys,
>
>
>
> Will you use groovy hot deploy in production environment? Is it reliable
> to do so?
>
>
>
> I am worried that it may have issue when you are doing below,
>
> 1, Defined a Array as class attribute, make it has 1 objects, next
> time code hot deploy that the array is erased in code, then that must be an
> memory leak, right?
>
> 2, If you execute a periodic timertask in a groovy, next time code hot
> deployed, if the timetask is no longer needed from your code, but the
> started timertask will still be running, right?
>
>
>
> If we demands developers avoid using class attributes or starting any
> thread thing as a development rule, will hot deploy still be good for
> production?
>
>
>
> Aplomb
>
>
>
> Best regards
>
>
>
> --
> Erwin Müller - erwin.muel...@deventm.org
> Software Entwickler - (+49) 01577-9505569
> Pgp - https://pgp.mit.edu/pks/lookup?op=get&search=0x02E820911DD910FD
> Meine Seite - http://www.mueller-public.de/
> ANRI - http://www.anr-institute.com/
>

Re: Is it possible to enable CompileStatic for an entire project

[Cédric Champeau]

Or use `@CompileDynamic` on your specs (that's the idea). But in any case,
the IDE will never interpret the script configuration file, so it won't
know that your classes are statically compiled, so won't show you the
proper errors.

2016-06-21 19:03 GMT+02:00 Mario Garcia :

> If I'm not wrong, projects like Spock doesn't like @CompileStatic so in
> case I would like to statically compile my project, at least I should be
> telling the compiler not to compile statically my specifications. Something
> like:
>
> withConfig(configuration) {
> source(unitValidator: { unit -> !unit.AST.classes.any {
> it.name.endsWith('Spec') } }) {
> ast(CompileStatic)
> }
> }
>
> my two cents
> Mario
>
> 2016-06-21 18:44 GMT+02:00 Cédric Champeau :
>
>> A strong -1 for both options. We already have 2 variants of Groovy today,
>> indy and non indy, and in practice *nobody uses the invokedynamic version*
>> because it's impractical to use. Typically projects depend on `groovy.jar`
>> or `groovy-all.jar`, not their invokedynamic version. Adding a new
>> dimension, which is orthogonal to invokedynamic makes it even more
>> complicated. Don't forget that the Groovy compiler is also mixed in its
>> runtime (which is a problem of its own). We should solve that first.
>>
>> Second, IDEs need to know whether a file is statically compiled or not.
>> The `@CompileStatic` annotation makes it very clear, and the default is the
>> standard dynamic mode that has been in Groovy for more than 10 years. IDEs
>> know about it, and it's simple to infer. Any alternative solution, like the
>> config script, or an alternate compiler (!) makes it impossible for the IDE
>> to guess. The only IDE-pragmatic solution is to have a distinct file
>> extension for statically compiled Groovy files (say, .sgroovy instead of
>> .groovy). So far this has been ruled out, but I think it's the most
>> pragmatic, and IDE friendly, solution.
>>
>>
>>
>> 2016-06-21 18:37 GMT+02:00 Mr Andersson :
>>
>>>
>>>
>>> On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:
>>>
>>> Tying Cédric’s advice to your previous question about gmavenplus and
>>> joint compilation, per
>>> https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script
>>> you add the configuration tag with a reference to your groovy script.
>>>
>>> I also mentioned that I could not get Gmavenplus to work, but maybe i
>>> did something wrong. But I literally copied and pasted that section.
>>>
>>>
>>>
>>> Actually about 90+% of our code base in Groovy is CompileStatic I wonder
>>> if we should use that. Cédric, if we use the config script method, is it
>>> still possible to use the “skip” annotation to switch back to dynamic mode?
>>> Even if it worked, I highly doubt IntelliJ IDEA would know about it and
>>> think all files are dynamic typing so probably it’s still best for us to
>>> add @CompileStatic everywhere, but sometimes we forget where we wanted it.
>>> The performance difference is extreme when we forget it, on a certain class
>>> we missed recently it took our page rendering times from about 4ms to 52ms,
>>> so for us it’s an actual “bug” to forget to add @CompileStatic.
>>>
>>>
>>> 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.
>>>
>>> *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.
>>>
>>>
>>>
>>>
>>> Jason
>>>
>>>
>>>
>>> *From:* Cédric Champeau [mailto:cedric.champ...@gmail.com
>>> ]
>>> *Sent:* Tuesday, June 21, 2016 8:29 AM
>>> *To:* users@groovy.apache.org
>>> *Subject:* Re: Is it possible to enable CompileStatic for an entire
>>> project
>>>
>>>
>>>
>>> It's in the docs:
>>> 
>>> http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
>>>
>>>
>>>
>>> 2016-06-21 14:24 GMT+02:00 Mr Andersson :
>>>
>>> Is it possible to enable CompileStatic for an entire project?
>>>
>>> Or do you have to do it on a per class basis?
>>>
>>> I like Groovy for some of it's features, and mostly for it's close to
>>> Java syntax but I would really like it to be a static language.
>>>
>>> I've heard about Groovy++ but I believe that's dead by now, no?
>>>
>>> Question is wether you can tell the 

Re: Is it possible to enable CompileStatic for an entire project

[Mario Garcia]

If I'm not wrong, projects like Spock doesn't like @CompileStatic so in
case I would like to statically compile my project, at least I should be
telling the compiler not to compile statically my specifications. Something
like:

withConfig(configuration) {
source(unitValidator: { unit -> !unit.AST.classes.any {
it.name.endsWith('Spec') } }) {
ast(CompileStatic)
}
}

my two cents
Mario

2016-06-21 18:44 GMT+02:00 Cédric Champeau :

> A strong -1 for both options. We already have 2 variants of Groovy today,
> indy and non indy, and in practice *nobody uses the invokedynamic version*
> because it's impractical to use. Typically projects depend on `groovy.jar`
> or `groovy-all.jar`, not their invokedynamic version. Adding a new
> dimension, which is orthogonal to invokedynamic makes it even more
> complicated. Don't forget that the Groovy compiler is also mixed in its
> runtime (which is a problem of its own). We should solve that first.
>
> Second, IDEs need to know whether a file is statically compiled or not.
> The `@CompileStatic` annotation makes it very clear, and the default is the
> standard dynamic mode that has been in Groovy for more than 10 years. IDEs
> know about it, and it's simple to infer. Any alternative solution, like the
> config script, or an alternate compiler (!) makes it impossible for the IDE
> to guess. The only IDE-pragmatic solution is to have a distinct file
> extension for statically compiled Groovy files (say, .sgroovy instead of
> .groovy). So far this has been ruled out, but I think it's the most
> pragmatic, and IDE friendly, solution.
>
>
>
> 2016-06-21 18:37 GMT+02:00 Mr Andersson :
>
>>
>>
>> On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:
>>
>> Tying Cédric’s advice to your previous question about gmavenplus and
>> joint compilation, per
>> https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script
>> you add the configuration tag with a reference to your groovy script.
>>
>> I also mentioned that I could not get Gmavenplus to work, but maybe i did
>> something wrong. But I literally copied and pasted that section.
>>
>>
>>
>> Actually about 90+% of our code base in Groovy is CompileStatic I wonder
>> if we should use that. Cédric, if we use the config script method, is it
>> still possible to use the “skip” annotation to switch back to dynamic mode?
>> Even if it worked, I highly doubt IntelliJ IDEA would know about it and
>> think all files are dynamic typing so probably it’s still best for us to
>> add @CompileStatic everywhere, but sometimes we forget where we wanted it.
>> The performance difference is extreme when we forget it, on a certain class
>> we missed recently it took our page rendering times from about 4ms to 52ms,
>> so for us it’s an actual “bug” to forget to add @CompileStatic.
>>
>>
>> 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.
>>
>> *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.
>>
>>
>>
>>
>> Jason
>>
>>
>>
>> *From:* Cédric Champeau [mailto:cedric.champ...@gmail.com
>> ]
>> *Sent:* Tuesday, June 21, 2016 8:29 AM
>> *To:* users@groovy.apache.org
>> *Subject:* Re: Is it possible to enable CompileStatic for an entire
>> project
>>
>>
>>
>> It's in the docs:
>> 
>> http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
>>
>>
>>
>> 2016-06-21 14:24 GMT+02:00 Mr Andersson :
>>
>> Is it possible to enable CompileStatic for an entire project?
>>
>> Or do you have to do it on a per class basis?
>>
>> I like Groovy for some of it's features, and mostly for it's close to
>> Java syntax but I would really like it to be a static language.
>>
>> I've heard about Groovy++ but I believe that's dead by now, no?
>>
>> Question is wether you can tell the Groovy compiler with a flag to treat
>> all Groovy classes on certain paths as static?
>>
>> Preferable doable from ANT too.
>>
>>
>> --
>> This email message and any attachments are for the sole use of the
>> intended recipient(s). Any unauthorized review, use, disclosure or
>> distribution is prohibited. If you are not the intended recipient, please
>> contact the sender by 

Re: Is it possible to enable CompileStatic for an entire project

[Cédric Champeau]

A strong -1 for both options. We already have 2 variants of Groovy today,
indy and non indy, and in practice *nobody uses the invokedynamic version*
because it's impractical to use. Typically projects depend on `groovy.jar`
or `groovy-all.jar`, not their invokedynamic version. Adding a new
dimension, which is orthogonal to invokedynamic makes it even more
complicated. Don't forget that the Groovy compiler is also mixed in its
runtime (which is a problem of its own). We should solve that first.

Second, IDEs need to know whether a file is statically compiled or not. The
`@CompileStatic` annotation makes it very clear, and the default is the
standard dynamic mode that has been in Groovy for more than 10 years. IDEs
know about it, and it's simple to infer. Any alternative solution, like the
config script, or an alternate compiler (!) makes it impossible for the IDE
to guess. The only IDE-pragmatic solution is to have a distinct file
extension for statically compiled Groovy files (say, .sgroovy instead of
.groovy). So far this has been ruled out, but I think it's the most
pragmatic, and IDE friendly, solution.



2016-06-21 18:37 GMT+02:00 Mr Andersson :

>
>
> On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:
>
> Tying Cédric’s advice to your previous question about gmavenplus and joint
> compilation, per
> https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script
> you add the configuration tag with a reference to your groovy script.
>
> I also mentioned that I could not get Gmavenplus to work, but maybe i did
> something wrong. But I literally copied and pasted that section.
>
>
>
> Actually about 90+% of our code base in Groovy is CompileStatic I wonder
> if we should use that. Cédric, if we use the config script method, is it
> still possible to use the “skip” annotation to switch back to dynamic mode?
> Even if it worked, I highly doubt IntelliJ IDEA would know about it and
> think all files are dynamic typing so probably it’s still best for us to
> add @CompileStatic everywhere, but sometimes we forget where we wanted it.
> The performance difference is extreme when we forget it, on a certain class
> we missed recently it took our page rendering times from about 4ms to 52ms,
> so for us it’s an actual “bug” to forget to add @CompileStatic.
>
>
> 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.
>
> *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.
>
>
>
>
> Jason
>
>
>
> *From:* Cédric Champeau [mailto:cedric.champ...@gmail.com
> ]
> *Sent:* Tuesday, June 21, 2016 8:29 AM
> *To:* users@groovy.apache.org
> *Subject:* Re: Is it possible to enable CompileStatic for an entire
> project
>
>
>
> It's in the docs:
> 
> http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
>
>
>
> 2016-06-21 14:24 GMT+02:00 Mr Andersson :
>
> Is it possible to enable CompileStatic for an entire project?
>
> Or do you have to do it on a per class basis?
>
> I like Groovy for some of it's features, and mostly for it's close to Java
> syntax but I would really like it to be a static language.
>
> I've heard about Groovy++ but I believe that's dead by now, no?
>
> Question is wether you can tell the Groovy compiler with a flag to treat
> all Groovy classes on certain paths as static?
>
> Preferable doable from ANT too.
>
>
> --
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>
>
>

Re: Is it possible to enable CompileStatic for an entire project

[Mr Andersson]

On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:


Tying Cédric’s advice to your previous question about gmavenplus and 
joint compilation, per 
https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you 
add the configuration tag with a reference to your groovy script.


I also mentioned that I could not get Gmavenplus to work, but maybe i 
did something wrong. But I literally copied and pasted that section.


Actually about 90+% of our code base in Groovy is CompileStatic I 
wonder if we should use that. Cédric, if we use the config script 
method, is it still possible to use the “skip” annotation to switch 
back to dynamic mode? Even if it worked, I highly doubt IntelliJ IDEA 
would know about it and think all files are dynamic typing so probably 
it’s still best for us to add @CompileStatic everywhere, but sometimes 
we forget where we wanted it. The performance difference is extreme 
when we forget it, on a certain class we missed recently it took our 
page rendering times from about 4ms to 52ms, so for us it’s an actual 
“bug” to forget to add @CompileStatic.




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.


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



Jason

*From:*Cédric Champeau [mailto:cedric.champ...@gmail.com]
*Sent:* Tuesday, June 21, 2016 8:29 AM
*To:* users@groovy.apache.org
*Subject:* Re: Is it possible to enable CompileStatic for an entire 
project


It's in the docs: 
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default


2016-06-21 14:24 GMT+02:00 Mr Andersson >:


Is it possible to enable CompileStatic for an entire project?

Or do you have to do it on a per class basis?

I like Groovy for some of it's features, and mostly for it's close
to Java syntax but I would really like it to be a static language.

I've heard about Groovy++ but I believe that's dead by now, no?

Question is wether you can tell the Groovy compiler with a flag to
treat all Groovy classes on certain paths as static?

Preferable doable from ANT too.


This email message and any attachments are for the sole use of the 
intended recipient(s). Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, 
please contact the sender by reply email and destroy all copies of the 
original message and any attachments.

Re: Is it possible to enable CompileStatic for an entire project

[Mr Andersson]

On 06/21/2016 02:38 PM, Winnebeck, Jason wrote:


Tying Cédric’s advice to your previous question about gmavenplus and 
joint compilation, per 
https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you 
add the configuration tag with a reference to your groovy script.


Actually about 90+% of our code base in Groovy is CompileStatic I 
wonder if we should use that. Cédric, if we use the config script 
method, is it still possible to use the “skip” annotation to switch 
back to dynamic mode? Even if it worked, I highly doubt IntelliJ IDEA 
would know about it and think all files are dynamic typing so probably 
it’s still best for us to add @CompileStatic everywhere, but sometimes 
we forget where we wanted it. The performance difference is extreme 
when we forget it, on a certain class we missed recently it took our 
page rendering times from about 4ms to 52ms, so for us it’s an actual 
“bug” to forget to add @CompileStatic.




Not to mention the fact that if you wish to enforce it across the 
organisation, you can't rely on start misusing the dynamic nature of 
Groovy.


Therefore, a default CompileStatic setting and a CompileDynamic 
annotation and you could track all of the dynamic usages easily in your 
editor. A missing CompileStatic is difficult to track.


Jason

*From:*Cédric Champeau [mailto:cedric.champ...@gmail.com]
*Sent:* Tuesday, June 21, 2016 8:29 AM
*To:* users@groovy.apache.org
*Subject:* Re: Is it possible to enable CompileStatic for an entire 
project


It's in the docs: 
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default


2016-06-21 14:24 GMT+02:00 Mr Andersson >:


Is it possible to enable CompileStatic for an entire project?

Or do you have to do it on a per class basis?

I like Groovy for some of it's features, and mostly for it's close
to Java syntax but I would really like it to be a static language.

I've heard about Groovy++ but I believe that's dead by now, no?

Question is wether you can tell the Groovy compiler with a flag to
treat all Groovy classes on certain paths as static?

Preferable doable from ANT too.


This email message and any attachments are for the sole use of the 
intended recipient(s). Any unauthorized review, use, disclosure or 
distribution is prohibited. If you are not the intended recipient, 
please contact the sender by reply email and destroy all copies of the 
original message and any attachments.

Re: Groovy hot deploy in production

[Domingo Suárez Torres]

I always avoid hot deployments, I prefer to have multiple running JVMs and
a proxy or load balancer in front.



On Tue, Jun 21, 2016 at 9:18 AM Erwin Müller 
wrote:

> Why not have start and stop hooks for such stuff?
>
> Have an interface with onStart() and onStop() methods, and call them when
> you load and unload a class.
>
> If you really need modularity, use OSGi.
>
> Regards, Erwin.
>
> Sun Jun 19 2016 15:00:56 CEST from "Aplomb Chen"  
> Subject:
> Groovy hot deploy in production
>
> Hi Guys,
>
>
>
> Will you use groovy hot deploy in production environment? Is it reliable
> to do so?
>
>
>
> I am worried that it may have issue when you are doing below,
>
> 1, Defined a Array as class attribute, make it has 1 objects, next
> time code hot deploy that the array is erased in code, then that must be an
> memory leak, right?
>
> 2, If you execute a periodic timertask in a groovy, next time code hot
> deployed, if the timetask is no longer needed from your code, but the
> started timertask will still be running, right?
>
>
>
> If we demands developers avoid using class attributes or starting any
> thread thing as a development rule, will hot deploy still be good for
> production?
>
>
>
> Aplomb
>
>
>
> Best regards
>
>
>
> --
> Erwin Müller - erwin.muel...@deventm.org
> Software Entwickler - (+49) 01577-9505569
> Pgp - https://pgp.mit.edu/pks/lookup?op=get&search=0x02E820911DD910FD
> Meine Seite - http://www.mueller-public.de/
> ANRI - http://www.anr-institute.com/
>

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

The annotations also work on classes, per the documentation:

When a class is annotated, all methods, properties, files, inner classes, etc. 
of the annotated class will be type checked. When a method is annotated, static 
compilation applies only to items (closures and anonymous inner clsses) within 
the method.

Jason

From: Charles G [mailto:charl...@gmail.com]
Sent: Tuesday, June 21, 2016 11:39 AM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

If we do it the doc way:  
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
would I just use 
http://docs.groovy-lang.org/next/html/gapi/groovy/transform/CompileDynamic.html
for classes I want to be dynamic -- or is it for methods only?

Docs: 
http://docs.groovy-lang.org/next/html/gapi/groovy/transform/CompileStatic.html  
seem to make it seem like you can only use it on methods?



On Tue, Jun 21, 2016 at 7:40 AM, Thibault Kruse 
mailto:tibokr...@googlemail.com>> wrote:
I would prefer to have a codenarc rule enforcing @CompileStatic for
projects requiring it that way.

On Tue, Jun 21, 2016 at 2:38 PM, Winnebeck, Jason
mailto:jason.winneb...@windstream.com>> wrote:
> Tying Cédric’s advice to your previous question about gmavenplus and joint
> compilation, per
> https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you
> add the configuration tag with a reference to your groovy script.
>
>
>
> Actually about 90+% of our code base in Groovy is CompileStatic I wonder if
> we should use that. Cédric, if we use the config script method, is it still
> possible to use the “skip” annotation to switch back to dynamic mode? Even
> if it worked, I highly doubt IntelliJ IDEA would know about it and think all
> files are dynamic typing so probably it’s still best for us to add
> @CompileStatic everywhere, but sometimes we forget where we wanted it. The
> performance difference is extreme when we forget it, on a certain class we
> missed recently it took our page rendering times from about 4ms to 52ms, so
> for us it’s an actual “bug” to forget to add @CompileStatic.
>
>
>
> Jason
>
>
>
> From: Cédric Champeau 
> [mailto:cedric.champ...@gmail.com]
> Sent: Tuesday, June 21, 2016 8:29 AM
> To: users@groovy.apache.org
> Subject: Re: Is it possible to enable CompileStatic for an entire project
>
>
>
> It's in the docs:
> http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
>
>
>
> 2016-06-21 14:24 GMT+02:00 Mr Andersson 
> mailto:mr.andersson@gmail.com>>:
>
> Is it possible to enable CompileStatic for an entire project?
>
> Or do you have to do it on a per class basis?
>
> I like Groovy for some of it's features, and mostly for it's close to Java
> syntax but I would really like it to be a static language.
>
> I've heard about Groovy++ but I believe that's dead by now, no?
>
> Question is wether you can tell the Groovy compiler with a flag to treat all
> Groovy classes on certain paths as static?
>
> Preferable doable from ANT too.
>
>
>
> 
> This email message and any attachments are for the sole use of the intended
> recipient(s). Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the sender
> by reply email and destroy all copies of the original message and any
> attachments.


--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Re: Is it possible to enable CompileStatic for an entire project

[Charles G]

If we do it the doc way:
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
would I just use
http://docs.groovy-lang.org/next/html/gapi/groovy/transform/CompileDynamic.html

for classes I want to be dynamic -- or is it for methods only?

Docs:
http://docs.groovy-lang.org/next/html/gapi/groovy/transform/CompileStatic.html
 seem to make it seem like you can only use it on methods?



On Tue, Jun 21, 2016 at 7:40 AM, Thibault Kruse 
wrote:

> I would prefer to have a codenarc rule enforcing @CompileStatic for
> projects requiring it that way.
>
> On Tue, Jun 21, 2016 at 2:38 PM, Winnebeck, Jason
>  wrote:
> > Tying Cédric’s advice to your previous question about gmavenplus and
> joint
> > compilation, per
> > https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script
> you
> > add the configuration tag with a reference to your groovy script.
> >
> >
> >
> > Actually about 90+% of our code base in Groovy is CompileStatic I wonder
> if
> > we should use that. Cédric, if we use the config script method, is it
> still
> > possible to use the “skip” annotation to switch back to dynamic mode?
> Even
> > if it worked, I highly doubt IntelliJ IDEA would know about it and think
> all
> > files are dynamic typing so probably it’s still best for us to add
> > @CompileStatic everywhere, but sometimes we forget where we wanted it.
> The
> > performance difference is extreme when we forget it, on a certain class
> we
> > missed recently it took our page rendering times from about 4ms to 52ms,
> so
> > for us it’s an actual “bug” to forget to add @CompileStatic.
> >
> >
> >
> > Jason
> >
> >
> >
> > From: Cédric Champeau [mailto:cedric.champ...@gmail.com]
> > Sent: Tuesday, June 21, 2016 8:29 AM
> > To: users@groovy.apache.org
> > Subject: Re: Is it possible to enable CompileStatic for an entire project
> >
> >
> >
> > It's in the docs:
> >
> http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
> >
> >
> >
> > 2016-06-21 14:24 GMT+02:00 Mr Andersson :
> >
> > Is it possible to enable CompileStatic for an entire project?
> >
> > Or do you have to do it on a per class basis?
> >
> > I like Groovy for some of it's features, and mostly for it's close to
> Java
> > syntax but I would really like it to be a static language.
> >
> > I've heard about Groovy++ but I believe that's dead by now, no?
> >
> > Question is wether you can tell the Groovy compiler with a flag to treat
> all
> > Groovy classes on certain paths as static?
> >
> > Preferable doable from ANT too.
> >
> >
> >
> > 
> > This email message and any attachments are for the sole use of the
> intended
> > recipient(s). Any unauthorized review, use, disclosure or distribution is
> > prohibited. If you are not the intended recipient, please contact the
> sender
> > by reply email and destroy all copies of the original message and any
> > attachments.
>

Re: Groovy hot deploy in production

[Erwin Müller]

Why not have start and stop hooks for such stuff?  

Have an interface with onStart() and onStop() methods, and call them when you
load and unload a class.  

If you really need modularity, use OSGi.  

Regards, Erwin.  
>  Sun Jun 19 2016 15:00:56 CEST from "Aplomb Chen"  
>Subject: Groovy hot deploy in production
>
>  
>
>Hi Guys,   
>
>   
>
>Will you use groovy hot deploy in production environment? Is it reliable to
>do so?  
>
>   
>
>I am worried that it may have issue when you are doing below,   
>
>1, Defined a Array as class attribute, make it has 1 objects, next time
>code hot deploy that the array is erased in code, then that must be an memory
>leak, right?  
>
>2, If you execute a periodic timertask in a groovy, next time code hot
>deployed, if the timetask is no longer needed from your code, but the started
>timertask will still be running, right?  
>
>   
>
>If we demands developers avoid using class attributes or starting any thread
>thing as a development rule, will hot deploy still be good for production?  
>
>   
>
>Aplomb  
>
>   
>
>Best regards  
>
>  
>
>
>
>  

  


   

-- 
Erwin Müller - erwin.muel...@deventm.org
Software Entwickler - (+49) 01577-9505569
Pgp - https://pgp.mit.edu/pks/lookup?op=get&search=0x02E820911DD910FD
Meine Seite - http://www.mueller-public.de/
ANRI - http://www.anr-institute.com/

Re: Using a groovy package from jruby

[Keegan Witt]

I don't think the Groovy-Eclipse plugin would be the one most would
recommend at this point.  JRuby and Groovy joint compilations aren't a very
common case, but I'd be happy to look at your GMavenPlus configuration.  It
should work.  Just make sure the stubs get generated.
If you're happy with using AntRun, I'm not gonna tell you to do otherwise.
But I'd appreciate seeing what you tried so I can correct any issues there
might be and/or improve documentation for others.

-Keegan

On Sat, Jun 18, 2016 at 7:19 PM, Charles Monteiro <
charles.monte...@gmail.com> wrote:

> Specifically one created from our source , I mention in case control of
> source matters, is this viable?
>
> --
> Charles Monteiro
>
> On June 18, 2016 at 2:12:54 PM, Mr Andersson (mr.andersson@gmail.com)
> wrote:
>
>> I was able to get it to work, both as separate groovy and java
>> directories and as one directory ( basically a groovy directory with mixed
>> ).
>>
>> It is interesting how complex this task was. It would appear as if the
>> Groovy community should have figured this out by now.
>>
>> I finally ( after 10 hours ) was able to get it to work, using only ANT.
>> The question is why Gmaven, GMaven2 Eclipse maven, and what not is even
>> mentioned when it is as simple as an ANT task.
>>
>> In constract, pulling in Scala and Kotlin ( during the process which I
>> gave up on Groovy ) took seconds.
>>
>> Relying on the Eclipse compiler is not a good thing as it has a history
>> of breaking and not being up to date with any other compiler that one might
>> wish to use.
>>
>> The solution ( note that I change some other things as well, like I don't
>> use src/main/java but just src ):
>>
>> 
>> 1.8
>> UTF-8
>> 4.0.6.RELEASE
>>
>> true
>> true
>>
>> ${basedir}/src
>> ${basedir}/test
>> 
>> ${project.build.directory}/WEB-INF/classes
>> 
>> ${project.build.directory}/WEB-INF/classes
>>
>>
>> ${myproject.src}${myproject.src}
>> ${myproject.srcOutput}${myproject.srcOutput}>
>>
>> 
>> true
>> org.apache.maven.plugins
>> maven-compiler-plugin
>> 3.5.1
>> 
>> ${java.version}
>> ${java.version}
>>
>> false
>> 
>>
>> 
>> 
>> default-compile
>> none
>> 
>> 
>> 
>> org.apache.maven.plugins
>> maven-antrun-plugin
>> 1.8
>> 
>> 
>> groovyc-compile
>> compile
>> 
>> 
>> > classname="org.codehaus.groovy.ant.Groovyc">
>> 
>> 
>>
>> 
>> 
>> > srcdir="${myproject.src}" listfiles="true">
>> 
>> 
>> 
>> 
>>
>> > encoding="UTF-8"/>
>> 
>>
>> 
>> 
>> 
>> run
>> 
>> 
>> 
>>
>>
>>
>>
>> On 06/18/2016 07:34 PM, Schalk W. Cronjé wrote:
>>
>> I dob't know about Ant, but in Gradle it us eady to get joint-compilation
>> of Groovy & Java if eerything is under the src/main/groovy folder.
>>
>>
>>
>> Sent from my Samsung device
>>
>>
>>  Original message 
>> From: Mr Andersson 
>> 
>> Date: 18/06/2016 18:39 (GMT+01:00)
>> To: users@groovy.apache.org
>> Subject: Re: Integrating Groovy with a Java EE application and Maven
>>
>> I have gotten a bit further in my research and came up with this sample
>> project which uses ant to compile the groovy classes but I can't get them
>> to compile together.
>>
>> To be able to have cyclic dependencies between Java and Groovy files.
>>
>> Here is a standalone isolated maven project that contains everything:
>>
>> http://www.speedyshare.com/TbQyG/Isolated.zip
>>
>> Pom file:
>>
>> > xmlns="http://maven.apache.org/POM/4.0.0"; 
>>  
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
>>  xsi:schem
>>  a
>> Location="http://maven.apache.org/POM/4.0.0 
>> http://maven.apache.org/maven-v4_0_0.xsd"; 
>> >
>> 4.0.0
>>
>> Isolated
>> Isolated
>> Isolated
>> 1.0
>> http://maven.apache.org
>>
>> jar
>>
>> 
>> 1.8
>> UTF-8
>> true
>> true
>> 
>>
>> 
>> 
>> org.codehaus.groovy
>> groovy-all
>> 2.4.6
>> 
>> 
>>
>> 
>>
>> 
>> 
>> true
>> org.apache.maven.plugins
>> maven-compiler-plugin
>> 3.5.1
>> 
>> ${java.version}
>> ${java.version}
>> 
>> 
>>
>>
>>  
>> maven-antrun-plugin
>>   

Re: Integrating Groovy with a Java EE application and Maven

[Keegan Witt]

Also the usage page  has
the two most common ways GMavenPlus is used.

-Keegan

On Tue, Jun 21, 2016 at 8:31 AM, Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> You are trying to do joint compilation so this is the only section you
> need:
> https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation
>
> The only difference from pure Groovy compile and joint compilation is you
> list the stub tasks to the goals. Basically all you do is add the
> gmavenplus-plugin and Groovy as a dependency.
>
> Jason
>
> -Original Message-
> From: Mr Andersson [mailto:mr.andersson@gmail.com]
> Sent: Tuesday, June 21, 2016 3:04 AM
> To: users@groovy.apache.org
> Subject: Re: Integrating Groovy with a Java EE application and Maven
>
> Gmaven or Gmaven 2 did not work for me either. Resulted in a bunch of
> compilation issues which I started to correct, but then gave up on. I
> shouldn't have to change my code to get on Groovy.
>
> I don't remember the exact errors, but there were some.
>
> I just tried again and it failed. I tried the join compilation but failed.
> Files were not recognized.
>
> Plus have you seen the size of this examples page?
>
> https://github.com/groovy/GMavenPlus/wiki/Examples
>
> Fifty ways to configure. I don't even know anything about what I need when
> i start off, so that's just too much headache.
>
> The ant task for me is good enough.
>
> See comments below.
>
> On 06/19/2016 02:09 PM, Jochen Theodorou wrote:
> > On 18.06.2016 20:12, Mr Andersson wrote:
> >> I was able to get it to work, both as separate groovy and java
> >> directories and as one directory ( basically a groovy directory with
> >> mixed ).
> >>
> >> It is interesting how complex this task was. It would appear as if
> >> the Groovy community should have figured this out by now.
> >
> > From the project side we support an ant task, command line and a
> > programmatic way to do joint compilation. The task is complex because
> > the build tools and the scenarios are. Gradle has much better support
> > for Groovy because we use it for our own build, but most of all,
> > because the Gradle people care.
> >
> >> I finally ( after 10 hours ) was able to get it to work, using only ANT.
> >> The question is why Gmaven, GMaven2 Eclipse maven, and what not is
> >> even mentioned when it is as simple as an ANT task.
> >
> > command line is even more simple ;)
>
> Not easy to integrate a command line argument for maven it seems. I am not
> sure how you can add that to the classpath. I was trying really hard on
> that but could not find any info, like with everything involving searching
> for Java issues. Google sucks at this, or the Java folks seriously do not
> ask or think enough about doing things the right way.
>
>
> https://www.google.pl/search?q=adding+to+maven+classpath&oq=adding+to+maven+classpath&aqs=chrome..69i57j0l5.10311j0j7&sourceid=chrome&es_sm=93&ie=UTF-8
>
> >
> >> In constract, pulling in Scala and Kotlin ( during the process which
> >> I gave up on Groovy ) took seconds.
> >
> > well, there are some maven people, here only very few
>
> Groovy has been alive for over 10 years. It has to be a couple of people
> wanting to integrate Groovy in a JEE environment by now.
>
> And I doubting the procedure is different for gradle.
> >
> >> Relying on the Eclipse compiler is not a good thing as it has a
> >> history of breaking and not being up to date with any other compiler
> >> that one might wish to use.
> >
> > Which is why the page suggests gmavenplus for maven... maybe that
> > should be more clear
>
> Did not work with both. The ant task should be the one mentioned because
> it will always succeed, unless you can figure how to add it to the
> classpath.
>
> >
> >> The solution ( note that I change some other things as well, like I
> >> don't use src/main/java but just src ):
> >>
> >> 
> >>  1.8
> >> UTF-8
> >> 4.0.6.RELEASE
> >>
> >>  true
> >>  true
> >>
> >>  ${basedir}/src
> >> ${basedir}/test
> >>
> ${project.build.directory}/WEB-INF/classes
> >>
> ${project.build.directory}/WEB-INF/classes
> >> 
> >>
> >>
> >> ${myproject.src}
> >> ${myproject.src}
> >>
> >> 
> >> ${myproject.srcOutput}
> >> ${myproject.srcOutput} >>
> >>
> >> 
> >>  true
> >>  org.apache.maven.plugins
> >>  maven-compiler-plugin
> >>  3.5.1
> >>  
> >>  ${java.version}
> >>  ${java.version}
> >>
> >>   false
> >>  
> >>
> >>  
> >>  
> >>  default-compile
> >>  none
> >>  
> >>  
> >>  
> >>  org.apache.maven.plugins
> >>  maven-antrun-plugin
> >>  1.8
> >>  
> >>  
> >>  groovyc-compile
> >>  compile
> >>  
> >>  
> >>   >> classname="org.codehaus.groovy.ant.Groovyc">
> >>  
> >>  
> >>
> >>  
> >>   

Re: Is it possible to enable CompileStatic for an entire project

[Thibault Kruse]

I would prefer to have a codenarc rule enforcing @CompileStatic for
projects requiring it that way.

On Tue, Jun 21, 2016 at 2:38 PM, Winnebeck, Jason
 wrote:
> Tying Cédric’s advice to your previous question about gmavenplus and joint
> compilation, per
> https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you
> add the configuration tag with a reference to your groovy script.
>
>
>
> Actually about 90+% of our code base in Groovy is CompileStatic I wonder if
> we should use that. Cédric, if we use the config script method, is it still
> possible to use the “skip” annotation to switch back to dynamic mode? Even
> if it worked, I highly doubt IntelliJ IDEA would know about it and think all
> files are dynamic typing so probably it’s still best for us to add
> @CompileStatic everywhere, but sometimes we forget where we wanted it. The
> performance difference is extreme when we forget it, on a certain class we
> missed recently it took our page rendering times from about 4ms to 52ms, so
> for us it’s an actual “bug” to forget to add @CompileStatic.
>
>
>
> Jason
>
>
>
> From: Cédric Champeau [mailto:cedric.champ...@gmail.com]
> Sent: Tuesday, June 21, 2016 8:29 AM
> To: users@groovy.apache.org
> Subject: Re: Is it possible to enable CompileStatic for an entire project
>
>
>
> It's in the docs:
> http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default
>
>
>
> 2016-06-21 14:24 GMT+02:00 Mr Andersson :
>
> Is it possible to enable CompileStatic for an entire project?
>
> Or do you have to do it on a per class basis?
>
> I like Groovy for some of it's features, and mostly for it's close to Java
> syntax but I would really like it to be a static language.
>
> I've heard about Groovy++ but I believe that's dead by now, no?
>
> Question is wether you can tell the Groovy compiler with a flag to treat all
> Groovy classes on certain paths as static?
>
> Preferable doable from ANT too.
>
>
>
> 
> This email message and any attachments are for the sole use of the intended
> recipient(s). Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the sender
> by reply email and destroy all copies of the original message and any
> attachments.

RE: Is it possible to enable CompileStatic for an entire project

[Winnebeck, Jason]

Tying Cédric’s advice to your previous question about gmavenplus and joint 
compilation, per 
https://github.com/groovy/GMavenPlus/wiki/Examples#configuration-script you add 
the configuration tag with a reference to your groovy script.

Actually about 90+% of our code base in Groovy is CompileStatic I wonder if we 
should use that. Cédric, if we use the config script method, is it still 
possible to use the “skip” annotation to switch back to dynamic mode? Even if 
it worked, I highly doubt IntelliJ IDEA would know about it and think all files 
are dynamic typing so probably it’s still best for us to add @CompileStatic 
everywhere, but sometimes we forget where we wanted it. The performance 
difference is extreme when we forget it, on a certain class we missed recently 
it took our page rendering times from about 4ms to 52ms, so for us it’s an 
actual “bug” to forget to add @CompileStatic.

Jason

From: Cédric Champeau [mailto:cedric.champ...@gmail.com]
Sent: Tuesday, June 21, 2016 8:29 AM
To: users@groovy.apache.org
Subject: Re: Is it possible to enable CompileStatic for an entire project

It's in the docs: 
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default

2016-06-21 14:24 GMT+02:00 Mr Andersson 
mailto:mr.andersson@gmail.com>>:
Is it possible to enable CompileStatic for an entire project?

Or do you have to do it on a per class basis?

I like Groovy for some of it's features, and mostly for it's close to Java 
syntax but I would really like it to be a static language.

I've heard about Groovy++ but I believe that's dead by now, no?

Question is wether you can tell the Groovy compiler with a flag to treat all 
Groovy classes on certain paths as static?

Preferable doable from ANT too.



--
This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Re: Is it possible to enable CompileStatic for an entire project

[Schalk Cronjé]

On 21/06/2016 13:29, Cédric Champeau wrote:
It's in the docs: 
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default

I am wondering how (or if) IntelliJ would recognise that?

--
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r

RE: Integrating Groovy with a Java EE application and Maven

[Winnebeck, Jason]

You are trying to do joint compilation so this is the only section you need:
https://github.com/groovy/GMavenPlus/wiki/Examples#joint-compilation

The only difference from pure Groovy compile and joint compilation is you list 
the stub tasks to the goals. Basically all you do is add the gmavenplus-plugin 
and Groovy as a dependency.

Jason

-Original Message-
From: Mr Andersson [mailto:mr.andersson@gmail.com] 
Sent: Tuesday, June 21, 2016 3:04 AM
To: users@groovy.apache.org
Subject: Re: Integrating Groovy with a Java EE application and Maven

Gmaven or Gmaven 2 did not work for me either. Resulted in a bunch of 
compilation issues which I started to correct, but then gave up on. I shouldn't 
have to change my code to get on Groovy.

I don't remember the exact errors, but there were some.

I just tried again and it failed. I tried the join compilation but failed. 
Files were not recognized.

Plus have you seen the size of this examples page?

https://github.com/groovy/GMavenPlus/wiki/Examples

Fifty ways to configure. I don't even know anything about what I need when i 
start off, so that's just too much headache.

The ant task for me is good enough.

See comments below.

On 06/19/2016 02:09 PM, Jochen Theodorou wrote:
> On 18.06.2016 20:12, Mr Andersson wrote:
>> I was able to get it to work, both as separate groovy and java 
>> directories and as one directory ( basically a groovy directory with 
>> mixed ).
>>
>> It is interesting how complex this task was. It would appear as if 
>> the Groovy community should have figured this out by now.
>
> From the project side we support an ant task, command line and a 
> programmatic way to do joint compilation. The task is complex because 
> the build tools and the scenarios are. Gradle has much better support 
> for Groovy because we use it for our own build, but most of all, 
> because the Gradle people care.
>
>> I finally ( after 10 hours ) was able to get it to work, using only ANT.
>> The question is why Gmaven, GMaven2 Eclipse maven, and what not is 
>> even mentioned when it is as simple as an ANT task.
>
> command line is even more simple ;)

Not easy to integrate a command line argument for maven it seems. I am not sure 
how you can add that to the classpath. I was trying really hard on that but 
could not find any info, like with everything involving searching for Java 
issues. Google sucks at this, or the Java folks seriously do not ask or think 
enough about doing things the right way.

https://www.google.pl/search?q=adding+to+maven+classpath&oq=adding+to+maven+classpath&aqs=chrome..69i57j0l5.10311j0j7&sourceid=chrome&es_sm=93&ie=UTF-8

>
>> In constract, pulling in Scala and Kotlin ( during the process which 
>> I gave up on Groovy ) took seconds.
>
> well, there are some maven people, here only very few

Groovy has been alive for over 10 years. It has to be a couple of people 
wanting to integrate Groovy in a JEE environment by now.

And I doubting the procedure is different for gradle.
>
>> Relying on the Eclipse compiler is not a good thing as it has a 
>> history of breaking and not being up to date with any other compiler 
>> that one might wish to use.
>
> Which is why the page suggests gmavenplus for maven... maybe that 
> should be more clear

Did not work with both. The ant task should be the one mentioned because it 
will always succeed, unless you can figure how to add it to the classpath.

>
>> The solution ( note that I change some other things as well, like I
>> don't use src/main/java but just src ):
>>
>> 
>>  1.8
>> UTF-8
>> 4.0.6.RELEASE
>>
>>  true
>>  true
>>
>>  ${basedir}/src
>> ${basedir}/test
>> ${project.build.directory}/WEB-INF/classes
>> ${project.build.directory}/WEB-INF/classes
>> 
>>
>>
>> ${myproject.src}
>> ${myproject.src}
>>
>>  
>> ${myproject.srcOutput}
>> ${myproject.srcOutput}>
>>
>> 
>>  true
>>  org.apache.maven.plugins
>>  maven-compiler-plugin
>>  3.5.1
>>  
>>  ${java.version}
>>  ${java.version}
>>
>>   false
>>  
>>
>>  
>>  
>>  default-compile
>>  none
>>  
>>  
>>  
>>  org.apache.maven.plugins
>>  maven-antrun-plugin
>>  1.8
>>  
>>  
>>  groovyc-compile
>>  compile
>>  
>>  
>>  > classname="org.codehaus.groovy.ant.Groovyc">
>>  
>>  
>>
>>  
>>  
>>  > srcdir="${myproject.src}" listfiles="true">
>>  
>>  
>>  
>>  
>>
>>  > encoding="UTF-8"/>
>>  
>>
>>  
>>  
>>  
>>  run
>>  
>>  
>>  
>> 
>
> I see, good to have that here. Now what are the main cons with this?

Re: Is it possible to enable CompileStatic for an entire project

[Cédric Champeau]

It's in the docs:
http://docs.groovy-lang.org/latest/html/documentation/#_static_compilation_by_default

2016-06-21 14:24 GMT+02:00 Mr Andersson :

> Is it possible to enable CompileStatic for an entire project?
>
> Or do you have to do it on a per class basis?
>
> I like Groovy for some of it's features, and mostly for it's close to Java
> syntax but I would really like it to be a static language.
>
> I've heard about Groovy++ but I believe that's dead by now, no?
>
> Question is wether you can tell the Groovy compiler with a flag to treat
> all Groovy classes on certain paths as static?
>
> Preferable doable from ANT too.
>
>
>

Is it possible to enable CompileStatic for an entire project

[Mr Andersson]

Is it possible to enable CompileStatic for an entire project?

Or do you have to do it on a per class basis?

I like Groovy for some of it's features, and mostly for it's close to 
Java syntax but I would really like it to be a static language.


I've heard about Groovy++ but I believe that's dead by now, no?

Question is wether you can tell the Groovy compiler with a flag to treat 
all Groovy classes on certain paths as static?


Preferable doable from ANT too.

Re: Integrating Groovy with a Java EE application and Maven

[Mr Andersson]

Gmaven or Gmaven 2 did not work for me either. Resulted in a bunch of 
compilation issues which I started to correct, but then gave up on. I 
shouldn't have to change my code to get on Groovy.


I don't remember the exact errors, but there were some.

I just tried again and it failed. I tried the join compilation but 
failed. Files were not recognized.


Plus have you seen the size of this examples page?

https://github.com/groovy/GMavenPlus/wiki/Examples

Fifty ways to configure. I don't even know anything about what I need 
when i start off, so that's just too much headache.


The ant task for me is good enough.

See comments below.

On 06/19/2016 02:09 PM, Jochen Theodorou wrote:

On 18.06.2016 20:12, Mr Andersson wrote:

I was able to get it to work, both as separate groovy and java
directories and as one directory ( basically a groovy directory with
mixed ).

It is interesting how complex this task was. It would appear as if the
Groovy community should have figured this out by now.


From the project side we support an ant task, command line and a 
programmatic way to do joint compilation. The task is complex because 
the build tools and the scenarios are. Gradle has much better support 
for Groovy because we use it for our own build, but most of all, 
because the Gradle people care.



I finally ( after 10 hours ) was able to get it to work, using only ANT.
The question is why Gmaven, GMaven2 Eclipse maven, and what not is even
mentioned when it is as simple as an ANT task.


command line is even more simple ;)


Not easy to integrate a command line argument for maven it seems. I am 
not sure how you can add that to the classpath. I was trying really hard 
on that but could not find any info, like with everything involving 
searching for Java issues. Google sucks at this, or the Java folks 
seriously do not ask or think enough about doing things the right way.


https://www.google.pl/search?q=adding+to+maven+classpath&oq=adding+to+maven+classpath&aqs=chrome..69i57j0l5.10311j0j7&sourceid=chrome&es_sm=93&ie=UTF-8




In constract, pulling in Scala and Kotlin ( during the process which I
gave up on Groovy ) took seconds.


well, there are some maven people, here only very few


Groovy has been alive for over 10 years. It has to be a couple of people 
wanting to integrate Groovy in a JEE environment by now.


And I doubting the procedure is different for gradle.



Relying on the Eclipse compiler is not a good thing as it has a history
of breaking and not being up to date with any other compiler that one
might wish to use.


Which is why the page suggests gmavenplus for maven... maybe that 
should be more clear


Did not work with both. The ant task should be the one mentioned because 
it will always succeed, unless you can figure how to add it to the 
classpath.





The solution ( note that I change some other things as well, like I
don't use src/main/java but just src ):


 1.8
UTF-8
4.0.6.RELEASE

 true
 true

 ${basedir}/src
${basedir}/test
${project.build.directory}/WEB-INF/classes
${project.build.directory}/WEB-INF/classes



${myproject.src}
${myproject.src}

 
${myproject.srcOutput}

${myproject.srcOutput}
 true
 org.apache.maven.plugins
 maven-compiler-plugin
 3.5.1
 
 ${java.version}
 ${java.version}

  false
 

 
 
 default-compile
 none
 
 
 
 org.apache.maven.plugins
 maven-antrun-plugin
 1.8
 
 
 groovyc-compile
 compile
 
 
 classname="org.codehaus.groovy.ant.Groovyc">

 
 

 
 
 srcdir="${myproject.src}" listfiles="true">

 
 
 
 

 encoding="UTF-8"/>

 

 
 
 
 run
 
 
 



I see, good to have that here. Now what are the main cons with this?

compared with gmaven plus:
* not really integrated in maven, thus you always compile all files


I am not sure what it means that you always compile all files. I haven't 
tried it enough but besides a 15 seconds extra build time, i don't see 
much difference in repetition.




compared with eclipse groovy plugin:
* stubs cannot compile as many scenarios as the integrated approach of 
the eclipse groovy compiler

* not really integrated in maven, thus you always compile all files

I am working on a new compiler tool for Groovy, which is supposed to 
have less of those disadvantages, for which I will then also look for 
more proper maven integration (I am hoping here on the help of gmaven 
plus). But that is still in the future and no fast project, because my 
free time is limited


bye Jochen



It should be simple, one plu