2.4.6 Windows Installer

[Keegan Witt]

The Windows installer for Groovy 2.4.6 is now available:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.4.6-
installer/view.  Now also includes Grengine
.

-Keegan

Re: Groovy Console wont start

[Keegan Witt]

Curious...it worked on both my Windows 10 home machine and my Windows 7
work machine.  What's you're JAVA_HOME environment variable set to?  Is it
a JDK?

I'm thinking maybe your JAVA_HOME isn't set, and you can't pass where Java
is as an arg because groovy.c

doesn't
take any args for groovyConsole.  I've been meaning to update the native
binaries, we've been in need of some changes for a while.  But first I
wanted to move it over to GNU Make so we can actually reliably build these
things (or change to Launch4j -- I'm not sure I get the original author's
objections to that idea).  I just haven't gotten it done yet...

In the mean time, I'd look at setting your JAVA_HOME, or j.ust keep using
the batch file.

-Keegan


On Fri, Mar 18, 2016 at 9:51 AM, Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> I understand you are green that's fine.
>
> I don't use the installer, so I didn't have groovyConsole.exe, but I did
> try the installer. My account is not an admin so I installed outside of
> Program Files, and for whatever reason I got no start menu entries, but all
> of the files did copy down. If I run groovyConsole.exe directly it did
> work. I'm not sure how groovyConsole.exe differs from the bat in terms of
> launching Groovy, or how the exe file is made.
>
> Jason
>
> -Original Message-
> From: Mart [mailto:m.a...@herts.ac.uk]
> Sent: Friday, March 18, 2016 8:47 AM
> To: us...@groovy.incubator.apache.org
> Subject: RE: Groovy Console wont start
>
> Thanks Jason
>
> Told you I was green
>
> The windows insall added  Start GroovyConsole to the start menu the
> properties being "C:\Program Files
> (x86)\Groovy\Groovy-2.4.6\bin\groovyConsole.exe".
>
> However running the GroovyConsole.bat does indeed start up the console. At
> least I know my Java_Home is ok!
>
> Any idea why groovyConsole.exe doesnt run?
>
> Mart
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Groovy-Console-wont-start-tp5731981p5731991.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>
> --
> 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.
>


On Fri, Mar 18, 2016 at 9:51 AM, Winnebeck, Jason <
jason.winneb...@windstream.com> wrote:

> I understand you are green that's fine.
>
> I don't use the installer, so I didn't have groovyConsole.exe, but I did
> try the installer. My account is not an admin so I installed outside of
> Program Files, and for whatever reason I got no start menu entries, but all
> of the files did copy down. If I run groovyConsole.exe directly it did
> work. I'm not sure how groovyConsole.exe differs from the bat in terms of
> launching Groovy, or how the exe file is made.
>
> Jason
>
> -Original Message-
> From: Mart [mailto:m.a...@herts.ac.uk]
> Sent: Friday, March 18, 2016 8:47 AM
> To: us...@groovy.incubator.apache.org
> Subject: RE: Groovy Console wont start
>
> Thanks Jason
>
> Told you I was green
>
> The windows insall added  Start GroovyConsole to the start menu the
> properties being "C:\Program Files
> (x86)\Groovy\Groovy-2.4.6\bin\groovyConsole.exe".
>
> However running the GroovyConsole.bat does indeed start up the console. At
> least I know my Java_Home is ok!
>
> Any idea why groovyConsole.exe doesnt run?
>
> Mart
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Groovy-Console-wont-start-tp5731981p5731991.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>
> --
> 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: does gmavenplus support lombok?

[Keegan Witt]

I haven't used Lombok, but wouldn't you just add Lombok as a dependency in
your POM?  Have you tried that already?

-Keegan
On May 10, 2016 2:07 AM, "Jochen Theodorou"  wrote:

> On 10.05.2016 03:31, SuoNayi wrote:
>
>> any comments，guys？
>>
>
> well... I did not found anything that looks like it would support it.
>
> by Jochen
>
>

2.4.7 Windows Installer

[Keegan Witt]

The Windows installer for Groovy 2.4.7 is now available:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.4.7-installer/view
.

-Keegan

Re: Integrating Groovy with a Java EE application and Maven

[Keegan Witt]

I put this page together to try to explain the pros and cons of different
tools: https://github.com/groovy/GMavenPlus/wiki/Choosing-Your-Build-Tool

-Keegan

On Sun, Jun 19, 2016 at 8:09 AM, 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 ;)
>
> 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
>
> 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
>
>
> 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
>
> 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
>
>

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

Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

I'm building some new binaries for Windows (groovy.exe, groovyConsole.exe,
etc) and am looking for some folks to test and code review it.  Their
temporary home is here: https://github.com/keeganwitt/groovy-binaries.
After I've incorporated any feedback I get, I'll transfer it to a repo
under the groovy org on Github (haven't decided yet whether that should be
groovy-windows-installer
 or
groovy-native-launcher ).

To make it easy to test, you can download the compiled binaries from here (
https://drive.google.com/folderview?id=0B_uOQFeu84v0TDVkS00xeE5yNHc&usp=sharing)
and put them in your current Groovy installation (whether from zip or
installer).

The overall approach is to have an exe that calls the matching .bat file.
This approach was to avoid a few things I didn't like about the current
binaries, namely
Windows installer determines 32 or 64 bit version of Java at install time
and installs the appropriate groovy.exe, but if you change your Java
version later, exe won't be able to run Groovy because it won't be able to
find right Java to invoke.
Binaries have their own logic to find Java, which adds unnecessary
complexity since the batch files maintained by the Groovy team already have
this logic.
Parameters are hard-coded into the binaries, coupling any change in
parameters between Groovy versions to that binary.
I'm not a Windows or C++ guy, so there are some things I'd like somebody's
thoughts on:
Am I following best practices in C++ source and Makefile?
Would it be better to have wmain() instead of main()?
Any better way to have done resource templating other than* sed*?
Would there be a reason to have chosen C over C++?
Any non-ASCII character hangups?
Running groovy.exe 象.groovy 象 seemed to invoke and pass argument in fine,
but it printed the arg as a question mark.  Although the current binaries
binaries do the same thing, so maybe it's a limitation of* cmd.exe*.
Does my strategy of passing args from exe to bat have any edge cases to
worry about with the use of system() and CreateProcess()?

-Keegan

Re: Static type checking

[Keegan Witt]

Mihail,
Instead of adding the whole candidate directory as a global library, just
add the Groovy 2.5.0 jar as a java lib.  That worked for me.

-Keegan


On Sat, Sep 3, 2016 at 9:38 AM, Mihai Cazacu  wrote:

> The issue is fixed now. Thank you!
>
> I just don't know how to use this new groovy version in IntellijIdea.
> Here it is what I did so far:
>
> cd ~/.sdkman/candidates/groovy
>> git clone https://github.com/apache/groovy.git groovy-2.5.0-SNAPSHOT
>> cd groovy-2.5.0-SNAPSHOT
>> ./gradlew clean dist
>> sdk u groovy 2.5.0-SNAPSHOT
>> groovy -v
>> Groovy Version: 2.5.0-SNAPSHOT JVM: 1.8.0_91 Vendor: Oracle Corporation
>> OS: Linux
>
>
> In IntellijIdea:
>
> Project Structure -> Global Libraries -> + (New Global Library) -> try to
>> select ~/.sdkman/candidates/groovy/groovy-2.5.0-SNAPSHOT but it is not
>> accepted.
>
>
> Instead, if I choose ~/.sdkman/candidates/groovy/groovy-2.4.7, everything
> works as expected.
>
> Is there a way to make this groovy version to be accepted by IntellijIdea?
>
> Thanks!
>

Re: Static type checking

[Keegan Witt]

Yea don't click that one (don't know why it doesn't work -- I even tried
switching out the Groovy jar version in IntelliJ's lib), instead click
Project Structure -> Libraries -> + -> Java, then select the jar.

-Keegan

On Sat, Sep 3, 2016 at 11:06 AM, cazacugmihai 
wrote:

> Hi Keegan!
>
> Can you write down those steps?
>
> If I'm opening a groovy file, IntellijIdea shows me a message in order to
> setup Groovy SDK:
> > "Groovy SDK is not configured for module... Configure Groovy SDK...".
>
> Pressing that message, a new window (title: "Setup Library") is opened.
> Here
> I only can to create a new library and
> ~/.sdkman/candidates/groovy/groovy-2.5.0-SNAPSHOT is not accepted.
>
> Best regards!
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Static-type-checking-tp5735162p5735194.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

Paco,
Good catch.  I'll correct that.

Raviteja,
That's correct, they are just wrappers.  The advantage is that you can set
file associations in Windows to an exe, but you can't associate a file type
with a bat file.  If you could, than you'd be right -- there'd be no reason
to have a wrapper.

-Keegan

On Wed, Sep 7, 2016 at 1:57 PM, Raviteja Lokineni <
raviteja.lokin...@gmail.com> wrote:

> I just glanced over the code and found that the cpp code just seems to be
> a wrapper on top of existing bat file. Although it is good that you wanted
> to contribute, I don't see the advantage in using exe file iff all it does
> is wrap existing bat file.
>
> Thanks,
> Raviteja
>
> On Wed, Sep 7, 2016 at 5:45 AM, Paco Zarate 
> wrote:
>
>> Hello Keegan!
>>
>> I was trying the new .exe files and i receive these errors when using the
>> commands without .exe:
>>
>> C:\WINDOWS\system32>groovyc -v
>> 'groobat' is not recognized as an internal or external command,
>> operable program or batch file.
>>
>> C:\WINDOWS\system32>groovy -v
>> 'grobat' is not recognized as an internal or external command,
>> operable program or batch file.
>>
>>
>> Including the .exe seems  to work fine:
>>
>> C:\WINDOWS\system32>groovy.exe -v
>> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle Corporation OS:
>> Windows 10
>>
>> C:\WINDOWS\system32>groovyc.exe -v
>> Groovy compiler version 2.4.7
>> Copyright 2003-2016 The Apache Software Foundation.
>> http://groovy-lang.org/
>>
>>
>> If i remove the JAVA_HOME env variable I get these responses:
>> C:\WINDOWS\system32>groovy.exe -v
>> 'MySQL' is not recognized as an internal or external command,
>> operable program or batch file.
>> 'MySQL' is not recognized as an internal or external command,
>> operable program or batch file.
>> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle Corporation OS:
>> Windows 10
>>
>> C:\WINDOWS\system32>groovyc.exe -v
>> 'MySQL' is not recognized as an internal or external command,
>> operable program or batch file.
>> 'MySQL' is not recognized as an internal or external command,
>> operable program or batch file.
>> Groovy compiler version 2.4.7
>> Copyright 2003-2016 The Apache Software Foundation.
>> http://groovy-lang.org/
>>
>> Thanks!!
>>
>> Paco.
>>
>> On Thu, Sep 1, 2016 at 2:05 PM, Keegan Witt  wrote:
>>
>>> I'm building some new binaries for Windows (groovy.exe,
>>> groovyConsole.exe, etc) and am looking for some folks to test and code
>>> review it.  Their temporary home is here: https://github.com/keega
>>> nwitt/groovy-binaries.  After I've incorporated any feedback I get,
>>> I'll transfer it to a repo under the groovy org on Github (haven't decided
>>> yet whether that should be groovy-windows-installer
>>> <https://github.com/groovy/groovy-windows-installer> or
>>> groovy-native-launcher
>>> <https://github.com/groovy/groovy-native-launcher>).
>>>
>>> To make it easy to test, you can download the compiled binaries from
>>> here (https://drive.google.com/folderview?id=0B_uOQFeu84v0TDVkS00
>>> xeE5yNHc&usp=sharing) and put them in your current Groovy installation
>>> (whether from zip or installer).
>>>
>>> The overall approach is to have an exe that calls the matching .bat
>>> file.  This approach was to avoid a few things I didn't like about the
>>> current binaries, namely
>>> Windows installer determines 32 or 64 bit version of Java at install
>>> time and installs the appropriate groovy.exe, but if you change your Java
>>> version later, exe won't be able to run Groovy because it won't be able to
>>> find right Java to invoke.
>>> Binaries have their own logic to find Java, which adds unnecessary
>>> complexity since the batch files maintained by the Groovy team already have
>>> this logic.
>>> Parameters are hard-coded into the binaries, coupling any change in
>>> parameters between Groovy versions to that binary.
>>> I'm not a Windows or C++ guy, so there are some things I'd like
>>> somebody's thoughts on:
>>> Am I following best practices in C++ source and Makefile?
>>> Would it be better to have wmain() instead of main()?
>>> Any better way to have done resource templating other than* sed*?
>>> Would there be a reason to have chosen C over C++?
>>> Any non-ASCII character hangups?
>>> Running groovy.exe 象.groovy 象 seemed to invoke and pass argument in
>>> fine, but it printed the arg as a question mark.  Although the current
>>> binaries binaries do the same thing, so maybe it's a limitation of*
>>> cmd.exe*.
>>> Does my strategy of passing args from exe to bat have any edge cases to
>>> worry about with the use of system() and CreateProcess()?
>>>
>>> -Keegan
>>>
>>
>>
>
>
> --
> *Raviteja Lokineni* | Business Intelligence Developer
> TD Ameritrade
>
> E: raviteja.lokin...@gmail.com
>
> [image: View Raviteja Lokineni's profile on LinkedIn]
> <http://in.linkedin.com/in/ravitejalokineni>
>
>

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

I've uploaded new executables to fix the issue with invoking without .exe
suffix.

-Keegan

On Wed, Sep 7, 2016 at 5:21 PM, Keegan Witt  wrote:

> Paco,
> Good catch.  I'll correct that.
>
> Raviteja,
> That's correct, they are just wrappers.  The advantage is that you can set
> file associations in Windows to an exe, but you can't associate a file type
> with a bat file.  If you could, than you'd be right -- there'd be no reason
> to have a wrapper.
>
> -Keegan
>
> On Wed, Sep 7, 2016 at 1:57 PM, Raviteja Lokineni <
> raviteja.lokin...@gmail.com> wrote:
>
>> I just glanced over the code and found that the cpp code just seems to be
>> a wrapper on top of existing bat file. Although it is good that you wanted
>> to contribute, I don't see the advantage in using exe file iff all it does
>> is wrap existing bat file.
>>
>> Thanks,
>> Raviteja
>>
>> On Wed, Sep 7, 2016 at 5:45 AM, Paco Zarate 
>> wrote:
>>
>>> Hello Keegan!
>>>
>>> I was trying the new .exe files and i receive these errors when using
>>> the commands without .exe:
>>>
>>> C:\WINDOWS\system32>groovyc -v
>>> 'groobat' is not recognized as an internal or external command,
>>> operable program or batch file.
>>>
>>> C:\WINDOWS\system32>groovy -v
>>> 'grobat' is not recognized as an internal or external command,
>>> operable program or batch file.
>>>
>>>
>>> Including the .exe seems  to work fine:
>>>
>>> C:\WINDOWS\system32>groovy.exe -v
>>> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle Corporation OS:
>>> Windows 10
>>>
>>> C:\WINDOWS\system32>groovyc.exe -v
>>> Groovy compiler version 2.4.7
>>> Copyright 2003-2016 The Apache Software Foundation.
>>> http://groovy-lang.org/
>>>
>>>
>>> If i remove the JAVA_HOME env variable I get these responses:
>>> C:\WINDOWS\system32>groovy.exe -v
>>> 'MySQL' is not recognized as an internal or external command,
>>> operable program or batch file.
>>> 'MySQL' is not recognized as an internal or external command,
>>> operable program or batch file.
>>> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle Corporation OS:
>>> Windows 10
>>>
>>> C:\WINDOWS\system32>groovyc.exe -v
>>> 'MySQL' is not recognized as an internal or external command,
>>> operable program or batch file.
>>> 'MySQL' is not recognized as an internal or external command,
>>> operable program or batch file.
>>> Groovy compiler version 2.4.7
>>> Copyright 2003-2016 The Apache Software Foundation.
>>> http://groovy-lang.org/
>>>
>>> Thanks!!
>>>
>>> Paco.
>>>
>>> On Thu, Sep 1, 2016 at 2:05 PM, Keegan Witt 
>>> wrote:
>>>
>>>> I'm building some new binaries for Windows (groovy.exe,
>>>> groovyConsole.exe, etc) and am looking for some folks to test and code
>>>> review it.  Their temporary home is here: https://github.com/keega
>>>> nwitt/groovy-binaries.  After I've incorporated any feedback I get,
>>>> I'll transfer it to a repo under the groovy org on Github (haven't decided
>>>> yet whether that should be groovy-windows-installer
>>>> <https://github.com/groovy/groovy-windows-installer> or
>>>> groovy-native-launcher
>>>> <https://github.com/groovy/groovy-native-launcher>).
>>>>
>>>> To make it easy to test, you can download the compiled binaries from
>>>> here (https://drive.google.com/folderview?id=0B_uOQFeu84v0TDVkS00
>>>> xeE5yNHc&usp=sharing) and put them in your current Groovy installation
>>>> (whether from zip or installer).
>>>>
>>>> The overall approach is to have an exe that calls the matching .bat
>>>> file.  This approach was to avoid a few things I didn't like about the
>>>> current binaries, namely
>>>> Windows installer determines 32 or 64 bit version of Java at install
>>>> time and installs the appropriate groovy.exe, but if you change your Java
>>>> version later, exe won't be able to run Groovy because it won't be able to
>>>> find right Java to invoke.
>>>> Binaries have their own logic to find Java, which adds unnecessary
>>>> complexity since the batch files maintained by the Groovy team already have

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

Hmm, maybe the bat files aren't as robust as I assumed and I should rethink
the approach.

If we went the GCJ route, we'd still have to implement our own logic to
locate Java binaries (similar to how C code does today), right?  That'd be
an option, though I'm a little hesitant to start relying on something that
looks like hasn't been updated in in several years and only supports Java
1.4 and some of Java 5.
Another option would be Launch4J, which is what I was originally
considering.  If we did that, we could even create 2 sets of binaries -- 1
with a bundled JRE, and 1 without.  What kinda drew me to that approach was
that it already had its own logic for locating Java.  I'll do some reading
on both options.

-Keegan

On Thu, Sep 8, 2016 at 8:27 AM, Jochen Theodorou  wrote:

> Maybe a stupid question... but couldn't we write an exe in Java and
> compile using gcj. The exe would spawn a new "normal" JVM and do the
> argument handling. Unlike the C variant there would be more people able to
> handle this.
>
> bye Jochen
>
> On 08.09.2016 11:13, Paul King wrote:
>
>> I think there are numerous problems with the argument passing in the
>> batch files. That was one of the things that the exe files aimed to
>> improve on. I must admit to having reservations about the new approach.
>> Not so much with the concept but more about relying on the current bat
>> files. That said, I am not sure staying with the current approach is
>> ideal either.
>>
>> Cheers, Paul.
>>
>> On Thu, Sep 8, 2016 at 4:57 PM, Paco Zarate > <mailto:conta...@nazcasistemas.com>> wrote:
>>
>> Hello Keegan
>> groovy and groovyc are working for me now! thanks!!
>>
>> The bat file seems to have an issue on Windows though:
>>
>> When the JAVA_HOME is not defined, and the PATH has an element with
>> & (ampersand), the groovy invocation seems to try to execute the
>> code after the & (eg. if mysql is installed there is a PATH defined to
>> "c:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL Utilities 1.5")
>> This is the output:
>> C:\WINDOWS\system32>groovy.bat -v
>> 'MySQL' is not recognized as an internal or external command,
>> operable program or batch file.
>> 'MySQL' is not recognized as an internal or external command,
>> operable program or batch file.
>> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle Corporation OS:
>> Windows 10
>>
>> I did this another test: I created an empty folder
>> "c:\Programs\sample1 & sample2" and added it to the PATH just before
>> "%GROOVY_HOME%\bin"
>>
>> When i run:
>> C:\WINDOWS\system32> groovy.bat -v
>>     'sample2' is not recognized as an internal or external command,
>> operable program or batch file.
>> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle Corporation OS:
>> Windows 10
>>
>> So it looks like an ampersand in an element in the PATH can affect
>> the groovy invocation.
>>
>> Paco
>>
>>
>>
>>
>> On Wed, Sep 7, 2016 at 8:39 PM, Keegan Witt > <mailto:keeganw...@gmail.com>> wrote:
>>
>> I've uploaded new executables to fix the issue with invoking
>> without .exe suffix.
>>
>> -Keegan
>>
>> On Wed, Sep 7, 2016 at 5:21 PM, Keegan Witt
>> mailto:keeganw...@gmail.com>> wrote:
>>
>> Paco,
>> Good catch.  I'll correct that.
>>
>> Raviteja,
>> That's correct, they are just wrappers.  The advantage is
>> that you can set file associations in Windows to an exe, but
>> you can't associate a file type with a bat file.  If you
>> could, than you'd be right -- there'd be no reason to have a
>> wrapper.
>>
>> -Keegan
>>
>> On Wed, Sep 7, 2016 at 1:57 PM, Raviteja Lokineni
>> > <mailto:raviteja.lokin...@gmail.com>> wrote:
>>
>> I just glanced over the code and found that the cpp code
>> just seems to be a wrapper on top of existing bat file.
>> Although it is good that you wanted to contribute, I
>> don't see the advantage in using exe file iff all it
>> does is wrap existing bat file.
>>
>> Tha

Groovy Docker images

[Keegan Witt]

I was thinking of putting together some Docker images for Groovy, with the
idea they might be useful to base Grails, Gradle, etc images on and
wondered people's opinions on a few things.

   - Should I install Groovy manually in somewhere like /opt?  Or use
   SDKMAN?
   - Should I have images based on Alpine and Debian? Alpine only?
   - I presume OpenJDK images are fine as bases?  Any reason we'd need an
   Oracle based image too?

Thoughts?

-Keegan

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

I started experimenting with launch4j, and have put that experiment in this
repo: https://github.com/keeganwitt/groovy-launch4j.  I've uploaded
binaries into same place I previous linked.  The first binaries I uploaded
are in batWrapper.zip, and the new launch4j based binaries are in
launch4j.zip if anyone wants to try them out.  At the moment, I only have
binaries that call Java (i.e. not bundled with Java).

-Keegan

On Fri, Sep 9, 2016 at 10:43 PM, Keegan Witt  wrote:

> Hmm, maybe the bat files aren't as robust as I assumed and I should
> rethink the approach.
>
> If we went the GCJ route, we'd still have to implement our own logic to
> locate Java binaries (similar to how C code does today), right?  That'd be
> an option, though I'm a little hesitant to start relying on something that
> looks like hasn't been updated in in several years and only supports Java
> 1.4 and some of Java 5.
> Another option would be Launch4J, which is what I was originally
> considering.  If we did that, we could even create 2 sets of binaries -- 1
> with a bundled JRE, and 1 without.  What kinda drew me to that approach was
> that it already had its own logic for locating Java.  I'll do some reading
> on both options.
>
> -Keegan
>
> On Thu, Sep 8, 2016 at 8:27 AM, Jochen Theodorou 
> wrote:
>
>> Maybe a stupid question... but couldn't we write an exe in Java and
>> compile using gcj. The exe would spawn a new "normal" JVM and do the
>> argument handling. Unlike the C variant there would be more people able to
>> handle this.
>>
>> bye Jochen
>>
>> On 08.09.2016 11:13, Paul King wrote:
>>
>>> I think there are numerous problems with the argument passing in the
>>> batch files. That was one of the things that the exe files aimed to
>>> improve on. I must admit to having reservations about the new approach.
>>> Not so much with the concept but more about relying on the current bat
>>> files. That said, I am not sure staying with the current approach is
>>> ideal either.
>>>
>>> Cheers, Paul.
>>>
>>> On Thu, Sep 8, 2016 at 4:57 PM, Paco Zarate >> <mailto:conta...@nazcasistemas.com>> wrote:
>>>
>>> Hello Keegan
>>> groovy and groovyc are working for me now! thanks!!
>>>
>>> The bat file seems to have an issue on Windows though:
>>>
>>> When the JAVA_HOME is not defined, and the PATH has an element with
>>> & (ampersand), the groovy invocation seems to try to execute the
>>> code after the & (eg. if mysql is installed there is a PATH defined
>>> to
>>> "c:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL Utilities
>>> 1.5")
>>> This is the output:
>>> C:\WINDOWS\system32>groovy.bat -v
>>> 'MySQL' is not recognized as an internal or external command,
>>> operable program or batch file.
>>> 'MySQL' is not recognized as an internal or external command,
>>> operable program or batch file.
>>> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle Corporation OS:
>>> Windows 10
>>>
>>> I did this another test: I created an empty folder
>>> "c:\Programs\sample1 & sample2" and added it to the PATH just before
>>> "%GROOVY_HOME%\bin"
>>>
>>> When i run:
>>> C:\WINDOWS\system32> groovy.bat -v
>>> 'sample2' is not recognized as an internal or external command,
>>> operable program or batch file.
>>> Groovy Version: 2.4.7 JVM: 1.8.0_101 Vendor: Oracle Corporation OS:
>>> Windows 10
>>>
>>> So it looks like an ampersand in an element in the PATH can affect
>>> the groovy invocation.
>>>
>>> Paco
>>>
>>>
>>>
>>>
>>> On Wed, Sep 7, 2016 at 8:39 PM, Keegan Witt >> <mailto:keeganw...@gmail.com>> wrote:
>>>
>>> I've uploaded new executables to fix the issue with invoking
>>> without .exe suffix.
>>>
>>> -Keegan
>>>
>>> On Wed, Sep 7, 2016 at 5:21 PM, Keegan Witt
>>> mailto:keeganw...@gmail.com>> wrote:
>>>
>>> Paco,
>>> Good catch.  I'll correct that.
>>>
>>> Raviteja,
>>> That's correct, they are just wrappers.  The advantage is
>>> that 

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

Hi Paco,
Thanks again for your help.  Yea, it assumes Gant will be installed in the
lib directory with the rest of the Groovy jars since that's how it's
installed by the Windows installer.  If you drop the jar in there, it
should work.

I'm mostly liking these so far.  The only thing I might be able to improve
on is that all the jars in lib are included in the classpath currently,
whereas the C binaries I think were more explicit in some cases (gant I
think being one of them).  I want to think through some more whether
there's any issues there.

-Keegan

On Mon, Oct 10, 2016 at 5:57 PM, Paco Zarate 
wrote:

> Keegan,
> The new .exe files look really good, I will keep using them. Even with a
> record in the PATH that includes an & (in a non-groovy related folder) it
> is working fine.
>
> The only error was:
> paco@DEVELOPER2 C:\Users\paco
> > gant
> Error: Could not find or load main class gant.Gant
>
> paco@DEVELOPER2 C:\Users\paco
> > gant.exe
> Error: Could not find or load main class gant.Gant
>
> paco@DEVELOPER2 C:\Users\paco
> > gant.exe -v
> Error: Could not find or load main class gant.Gant
>
> But i think i am missing the gant install, i will read more about how to
> install gant correctly later today and let you know.
>
> Paco.
>
> On Mon, Sep 26, 2016 at 12:18 PM, Keegan Witt 
> wrote:
>
>> I started experimenting with launch4j, and have put that experiment in
>> this repo: https://github.com/keeganwitt/groovy-launch4j.  I've uploaded
>> binaries into same place I previous linked.  The first binaries I uploaded
>> are in batWrapper.zip, and the new launch4j based binaries are in
>> launch4j.zip if anyone wants to try them out.  At the moment, I only have
>> binaries that call Java (i.e. not bundled with Java).
>>
>> -Keegan
>>
>> On Fri, Sep 9, 2016 at 10:43 PM, Keegan Witt 
>> wrote:
>>
>>> Hmm, maybe the bat files aren't as robust as I assumed and I should
>>> rethink the approach.
>>>
>>> If we went the GCJ route, we'd still have to implement our own logic to
>>> locate Java binaries (similar to how C code does today), right?  That'd be
>>> an option, though I'm a little hesitant to start relying on something that
>>> looks like hasn't been updated in in several years and only supports Java
>>> 1.4 and some of Java 5.
>>> Another option would be Launch4J, which is what I was originally
>>> considering.  If we did that, we could even create 2 sets of binaries -- 1
>>> with a bundled JRE, and 1 without.  What kinda drew me to that approach was
>>> that it already had its own logic for locating Java.  I'll do some reading
>>> on both options.
>>>
>>> -Keegan
>>>
>>> On Thu, Sep 8, 2016 at 8:27 AM, Jochen Theodorou 
>>> wrote:
>>>
>>>> Maybe a stupid question... but couldn't we write an exe in Java and
>>>> compile using gcj. The exe would spawn a new "normal" JVM and do the
>>>> argument handling. Unlike the C variant there would be more people able to
>>>> handle this.
>>>>
>>>> bye Jochen
>>>>
>>>> On 08.09.2016 11:13, Paul King wrote:
>>>>
>>>>> I think there are numerous problems with the argument passing in the
>>>>> batch files. That was one of the things that the exe files aimed to
>>>>> improve on. I must admit to having reservations about the new approach.
>>>>> Not so much with the concept but more about relying on the current bat
>>>>> files. That said, I am not sure staying with the current approach is
>>>>> ideal either.
>>>>>
>>>>> Cheers, Paul.
>>>>>
>>>>> On Thu, Sep 8, 2016 at 4:57 PM, Paco Zarate <
>>>>> conta...@nazcasistemas.com
>>>>> <mailto:conta...@nazcasistemas.com>> wrote:
>>>>>
>>>>> Hello Keegan
>>>>> groovy and groovyc are working for me now! thanks!!
>>>>>
>>>>> The bat file seems to have an issue on Windows though:
>>>>>
>>>>> When the JAVA_HOME is not defined, and the PATH has an element with
>>>>> & (ampersand), the groovy invocation seems to try to execute the
>>>>> code after the & (eg. if mysql is installed there is a PATH
>>>>> defined to
>>>>> "c:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL Utilities
>>>>> 1.5")
>>>>

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

Actually question I guess would be whether we even need a gant.exe.  Nobody
really doubleclicks gant files that I'm aware of.

-Keegan

On Tue, Oct 11, 2016 at 4:34 PM, Keegan Witt  wrote:

> Hi Paco,
> Thanks again for your help.  Yea, it assumes Gant will be installed in the
> lib directory with the rest of the Groovy jars since that's how it's
> installed by the Windows installer.  If you drop the jar in there, it
> should work.
>
> I'm mostly liking these so far.  The only thing I might be able to improve
> on is that all the jars in lib are included in the classpath currently,
> whereas the C binaries I think were more explicit in some cases (gant I
> think being one of them).  I want to think through some more whether
> there's any issues there.
>
> -Keegan
>
> On Mon, Oct 10, 2016 at 5:57 PM, Paco Zarate 
> wrote:
>
>> Keegan,
>> The new .exe files look really good, I will keep using them. Even with a
>> record in the PATH that includes an & (in a non-groovy related folder) it
>> is working fine.
>>
>> The only error was:
>> paco@DEVELOPER2 C:\Users\paco
>> > gant
>> Error: Could not find or load main class gant.Gant
>>
>> paco@DEVELOPER2 C:\Users\paco
>> > gant.exe
>> Error: Could not find or load main class gant.Gant
>>
>> paco@DEVELOPER2 C:\Users\paco
>> > gant.exe -v
>> Error: Could not find or load main class gant.Gant
>>
>> But i think i am missing the gant install, i will read more about how to
>> install gant correctly later today and let you know.
>>
>> Paco.
>>
>> On Mon, Sep 26, 2016 at 12:18 PM, Keegan Witt 
>> wrote:
>>
>>> I started experimenting with launch4j, and have put that experiment in
>>> this repo: https://github.com/keeganwitt/groovy-launch4j.  I've
>>> uploaded binaries into same place I previous linked.  The first binaries I
>>> uploaded are in batWrapper.zip, and the new launch4j based binaries are in
>>> launch4j.zip if anyone wants to try them out.  At the moment, I only have
>>> binaries that call Java (i.e. not bundled with Java).
>>>
>>> -Keegan
>>>
>>> On Fri, Sep 9, 2016 at 10:43 PM, Keegan Witt 
>>> wrote:
>>>
>>>> Hmm, maybe the bat files aren't as robust as I assumed and I should
>>>> rethink the approach.
>>>>
>>>> If we went the GCJ route, we'd still have to implement our own logic to
>>>> locate Java binaries (similar to how C code does today), right?  That'd be
>>>> an option, though I'm a little hesitant to start relying on something that
>>>> looks like hasn't been updated in in several years and only supports Java
>>>> 1.4 and some of Java 5.
>>>> Another option would be Launch4J, which is what I was originally
>>>> considering.  If we did that, we could even create 2 sets of binaries -- 1
>>>> with a bundled JRE, and 1 without.  What kinda drew me to that approach was
>>>> that it already had its own logic for locating Java.  I'll do some reading
>>>> on both options.
>>>>
>>>> -Keegan
>>>>
>>>> On Thu, Sep 8, 2016 at 8:27 AM, Jochen Theodorou 
>>>> wrote:
>>>>
>>>>> Maybe a stupid question... but couldn't we write an exe in Java and
>>>>> compile using gcj. The exe would spawn a new "normal" JVM and do the
>>>>> argument handling. Unlike the C variant there would be more people able to
>>>>> handle this.
>>>>>
>>>>> bye Jochen
>>>>>
>>>>> On 08.09.2016 11:13, Paul King wrote:
>>>>>
>>>>>> I think there are numerous problems with the argument passing in the
>>>>>> batch files. That was one of the things that the exe files aimed to
>>>>>> improve on. I must admit to having reservations about the new
>>>>>> approach.
>>>>>> Not so much with the concept but more about relying on the current bat
>>>>>> files. That said, I am not sure staying with the current approach is
>>>>>> ideal either.
>>>>>>
>>>>>> Cheers, Paul.
>>>>>>
>>>>>> On Thu, Sep 8, 2016 at 4:57 PM, Paco Zarate <
>>>>>> conta...@nazcasistemas.com
>>>>>> <mailto:conta...@nazcasistemas.com>> wrote:
>>>>>>
>>>>>> Hello Keegan
>>>>>> groovy 

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

Well there's the bat file in bin.  Might be good to keep it there at least
initially, as a transition though.

-Keegan

On Oct 11, 2016 4:58 PM, "Paco Zarate"  wrote:

> I would suggest to keep the gant.exe, it makes really clear that you can
> execute that one on Windows. Otherwise I would not know that the
> application is there. (as in Linux where you can see the .sh files)
>
> On Tue, Oct 11, 2016 at 2:49 PM, Keegan Witt  wrote:
>
>> Actually question I guess would be whether we even need a gant.exe.
>> Nobody really doubleclicks gant files that I'm aware of.
>>
>> -Keegan
>>
>> On Tue, Oct 11, 2016 at 4:34 PM, Keegan Witt 
>> wrote:
>>
>>> Hi Paco,
>>> Thanks again for your help.  Yea, it assumes Gant will be installed in
>>> the lib directory with the rest of the Groovy jars since that's how it's
>>> installed by the Windows installer.  If you drop the jar in there, it
>>> should work.
>>>
>>> I'm mostly liking these so far.  The only thing I might be able to
>>> improve on is that all the jars in lib are included in the classpath
>>> currently, whereas the C binaries I think were more explicit in some cases
>>> (gant I think being one of them).  I want to think through some more
>>> whether there's any issues there.
>>>
>>> -Keegan
>>>
>>> On Mon, Oct 10, 2016 at 5:57 PM, Paco Zarate >> > wrote:
>>>
>>>> Keegan,
>>>> The new .exe files look really good, I will keep using them. Even with
>>>> a record in the PATH that includes an & (in a non-groovy related folder) it
>>>> is working fine.
>>>>
>>>> The only error was:
>>>> paco@DEVELOPER2 C:\Users\paco
>>>> > gant
>>>> Error: Could not find or load main class gant.Gant
>>>>
>>>> paco@DEVELOPER2 C:\Users\paco
>>>> > gant.exe
>>>> Error: Could not find or load main class gant.Gant
>>>>
>>>> paco@DEVELOPER2 C:\Users\paco
>>>> > gant.exe -v
>>>> Error: Could not find or load main class gant.Gant
>>>>
>>>> But i think i am missing the gant install, i will read more about how
>>>> to install gant correctly later today and let you know.
>>>>
>>>> Paco.
>>>>
>>>> On Mon, Sep 26, 2016 at 12:18 PM, Keegan Witt 
>>>> wrote:
>>>>
>>>>> I started experimenting with launch4j, and have put that experiment in
>>>>> this repo: https://github.com/keeganwitt/groovy-launch4j.  I've
>>>>> uploaded binaries into same place I previous linked.  The first binaries I
>>>>> uploaded are in batWrapper.zip, and the new launch4j based binaries are in
>>>>> launch4j.zip if anyone wants to try them out.  At the moment, I only have
>>>>> binaries that call Java (i.e. not bundled with Java).
>>>>>
>>>>> -Keegan
>>>>>
>>>>> On Fri, Sep 9, 2016 at 10:43 PM, Keegan Witt 
>>>>> wrote:
>>>>>
>>>>>> Hmm, maybe the bat files aren't as robust as I assumed and I should
>>>>>> rethink the approach.
>>>>>>
>>>>>> If we went the GCJ route, we'd still have to implement our own logic
>>>>>> to locate Java binaries (similar to how C code does today), right?  
>>>>>> That'd
>>>>>> be an option, though I'm a little hesitant to start relying on something
>>>>>> that looks like hasn't been updated in in several years and only supports
>>>>>> Java 1.4 and some of Java 5.
>>>>>> Another option would be Launch4J, which is what I was originally
>>>>>> considering.  If we did that, we could even create 2 sets of binaries -- 
>>>>>> 1
>>>>>> with a bundled JRE, and 1 without.  What kinda drew me to that approach 
>>>>>> was
>>>>>> that it already had its own logic for locating Java.  I'll do some 
>>>>>> reading
>>>>>> on both options.
>>>>>>
>>>>>> -Keegan
>>>>>>
>>>>>> On Thu, Sep 8, 2016 at 8:27 AM, Jochen Theodorou 
>>>>>> wrote:
>>>>>>
>>>>>>> Maybe a stupid question... but couldn't we write an exe in Java and
>>>>>>> compile using gcj. The exe would spawn a new &q

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

It's not direct in the same sense as your gcj idea.  It's more like the
original native binaries where it finds Java, then invokes it with a
specified classpath and main class.  I'm just using launch4j to do that
instead of my own code.

-Keegan

On Mon, Oct 17, 2016 at 12:39 PM, Jochen Theodorou 
wrote:

> Does this mean the binary calls GroovyMain directly?
>
>
> On 17.10.2016 18:20, Paco Zarate wrote:
>
>> Hey Keegan,
>> Looks like there is a problem with Grapes and the .exe files:
>> I am attaching the test code (a sqlite example from SO)
>>
>> When i use the groovy.bat i got:
>> c:\Data\Samples\Groovy\sqlite>groovy.bat samplesqlite.groovy
>> id=1, name= leo
>> id=2, name= yui
>>
>> When i use the groovy.exe i got this error:
>> c:\Data\Samples\Groovy\sqlite>groovy.exe samplesqlite.groovy
>> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
>> failed:
>> General error during conversion: No suitable ClassLoader found for grab
>>
>> java.lang.RuntimeException: No suitable ClassLoader found for grab
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>> at
>> sun.reflect.NativeConstructorAccessorImpl.newInstance(Native
>> ConstructorAccessorImpl.java:62)
>> at
>> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De
>> legatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> at
>> org.codehaus.groovy.reflection.CachedConstructor.invoke(
>> CachedConstructor.java:83)
>> at
>> org.codehaus.groovy.runtime.callsite.ConstructorSite$Constru
>> ctorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>> at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCa
>> llConstructor(CallSiteArray.java:60)
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCo
>> nstructor(AbstractCallSite.java:235)
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCo
>> nstructor(AbstractCallSite.java:247)
>> at groovy.grape.GrapeIvy.chooseClassLoader(GrapeIvy.groovy:184)
>> at groovy.grape.GrapeIvy$chooseClassLoader.callCurrent(Unknown
>> Source)
>> at
>> org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCa
>> llCurrent(CallSiteArray.java:52)
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCu
>> rrent(AbstractCallSite.java:154)
>> at
>> org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCu
>> rrent(AbstractCallSite.java:166)
>> at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:251)
>> at groovy.grape.Grape.grab(Grape.java:167)
>> at
>> groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotati
>> onTransformation.java:378)
>> at
>> org.codehaus.groovy.transform.ASTTransformationVisitor$3.cal
>> l(ASTTransformationVisitor.java:321)
>> at
>> org.codehaus.groovy.control.CompilationUnit.applyToSourceUni
>> ts(CompilationUnit.java:931)
>> at
>> org.codehaus.groovy.control.CompilationUnit.doPhaseOperation
>> (CompilationUnit.java:593)
>> at
>> org.codehaus.groovy.control.CompilationUnit.processPhaseOper
>> ations(CompilationUnit.java:569)
>> at
>> org.codehaus.groovy.control.CompilationUnit.compile(Compilat
>> ionUnit.java:546)
>> at
>> groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
>> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.j
>> ava:268)
>> at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
>>     at groovy.lang.GroovyShell.run(GroovyShell.java:517)
>> at groovy.lang.GroovyShell.run(GroovyShell.java:507)
>> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:653)
>> at groovy.ui.GroovyMain.run(GroovyMain.java:384)
>> at groovy.ui.GroovyMain.process(GroovyMain.java:370)
>> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:129)
>> at groovy.ui.GroovyMain.main(GroovyMain.java:109)
>>
>> 1 error
>>
>> Thanks!
>> Paco.
>>
>>
>>
>> On Tue, Oct 11, 2016 at 4:50 PM, Keegan Witt > <mailto:keeganw...@gmail.com>> wrote:
>>
>> Well there's the bat file in bin.  Might be good to keep it there at
>> least initially, as a transition though.
>>
>> -Keegan
>>
>>
>> On Oct 11, 2016 4:58 PM, "Paco Zarate" > <mailto:conta...@nazcasistemas.com>> wrote:
>>
>>  

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

Thanks Paco,
It looks like it's related to @GrabConfig(systemClassLoader=true), I'm
looking into it.

-Keegan

On Mon, Oct 17, 2016 at 12:20 PM, Paco Zarate 
wrote:

> Hey Keegan,
> Looks like there is a problem with Grapes and the .exe files:
> I am attaching the test code (a sqlite example from SO)
>
> When i use the groovy.bat i got:
> c:\Data\Samples\Groovy\sqlite>groovy.bat samplesqlite.groovy
> id=1, name= leo
> id=2, name= yui
>
> When i use the groovy.exe i got this error:
> c:\Data\Samples\Groovy\sqlite>groovy.exe samplesqlite.groovy
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> General error during conversion: No suitable ClassLoader found for grab
>
> java.lang.RuntimeException: No suitable ClassLoader found for grab
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
> Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(
> NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(
> DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at org.codehaus.groovy.reflection.CachedConstructor.
> invoke(CachedConstructor.java:83)
> at org.codehaus.groovy.runtime.callsite.ConstructorSite$
> ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.
> defaultCallConstructor(CallSiteArray.java:60)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.
> callConstructor(AbstractCallSite.java:235)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.
> callConstructor(AbstractCallSite.java:247)
> at groovy.grape.GrapeIvy.chooseClassLoader(GrapeIvy.groovy:184)
> at groovy.grape.GrapeIvy$chooseClassLoader.callCurrent(Unknown Source)
> at org.codehaus.groovy.runtime.callsite.CallSiteArray.
> defaultCallCurrent(CallSiteArray.java:52)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.
> callCurrent(AbstractCallSite.java:154)
> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.
> callCurrent(AbstractCallSite.java:166)
> at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:251)
> at groovy.grape.Grape.grab(Grape.java:167)
> at groovy.grape.GrabAnnotationTransformation.visit(
> GrabAnnotationTransformation.java:378)
> at org.codehaus.groovy.transform.ASTTransformationVisitor$3.
> call(ASTTransformationVisitor.java:321)
> at org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(
> CompilationUnit.java:931)
> at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(
> CompilationUnit.java:593)
> at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(
> CompilationUnit.java:569)
> at org.codehaus.groovy.control.CompilationUnit.compile(
> CompilationUnit.java:546)
> at groovy.lang.GroovyClassLoader.doParseClass(
> GroovyClassLoader.java:298)
> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.
> java:268)
> at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
> at groovy.lang.GroovyShell.run(GroovyShell.java:517)
> at groovy.lang.GroovyShell.run(GroovyShell.java:507)
> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:653)
> at groovy.ui.GroovyMain.run(GroovyMain.java:384)
> at groovy.ui.GroovyMain.process(GroovyMain.java:370)
> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:129)
> at groovy.ui.GroovyMain.main(GroovyMain.java:109)
>
> 1 error
>
> Thanks!
> Paco.
>
>
>
> On Tue, Oct 11, 2016 at 4:50 PM, Keegan Witt  wrote:
>
>> Well there's the bat file in bin.  Might be good to keep it there at
>> least initially, as a transition though.
>>
>> -Keegan
>>
>> On Oct 11, 2016 4:58 PM, "Paco Zarate" 
>> wrote:
>>
>>> I would suggest to keep the gant.exe, it makes really clear that you can
>>> execute that one on Windows. Otherwise I would not know that the
>>> application is there. (as in Linux where you can see the .sh files)
>>>
>>> On Tue, Oct 11, 2016 at 2:49 PM, Keegan Witt 
>>> wrote:
>>>
>>>> Actually question I guess would be whether we even need a gant.exe.
>>>> Nobody really doubleclicks gant files that I'm aware of.
>>>>
>>>> -Keegan
>>>>
>>>> On Tue, Oct 11, 2016 at 4:34 PM, Keegan Witt 
>>>> wrote:
>>>>
>>>>> Hi Paco,
>>>>> Thanks again for your help.  Yea, it assumes Gant will be installed in
>>>>> the lib directory with the rest of the Groovy jars since

Re: Congratulations to our newest committer Daniel Sun

[Keegan Witt]

Welcome Daniel!

-Keegan


On Sat, Nov 5, 2016 at 8:40 AM, Cédric Champeau 
wrote:

> Congrats, Daniel!
>
> 2016-11-05 9:33 GMT+01:00 Daniel.Sun :
>
>> Thanks :)
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>> --
>> View this message in context: http://groovy.329449.n5.nabble
>> .com/Congratulations-to-our-newest-committer-Daniel-Sun-
>> tp5736468p5736502.html
>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>
>
>

Re: GMavenPlus compiles stubs

[Keegan Witt]

Jochen is right, Groovy compilation happens after stubgen and javac, hence
it'll replace those previously generated classes.

Why shouldn't javac compile the stubs?  Wouldn't javac need the classes so
that it has something to compile against (since Java is statically
compiled) so that circular compilation works?  GMaven worked this way also.

-Keegan

On Nov 21, 2016 4:36 PM, "Jochen Theodorou"  wrote:

> On 21.11.2016 23:08, Winnebeck, Jason wrote:
>
>> I recently encountered an error from javac compiling a stub that was
>> otherwise valid from Groovy itself when I enabled generate-stubs task. I
>> resolved the error properly, but I wonder, should javac be compiling
>> stubs when using gmavenplus?
>>
>
> afaik no
>
> I thought it just referred to them but did
>> not compile them. If it’s compiling the stubs, am I at risk of having
>> the stub replace the Groovy-generated code in the final jar?
>>
>
> since groovy compilation happens after the groovy compiler will overwrite
> those classes. So no danger from that front
>
> bye Jochen
>

Re: Groovy Docker images

[Keegan Witt]

Sorry for the long turnaround on this.  I've got some basic Dockerfiles put
together: https://github.com/keeganwitt/groovy-docker.  Please let me know
what I can improve.  One thing I might do is template out the Dockerfiles
similar to what Ruby did <https://github.com/docker-library/ruby> to make
it easier to publish images when there's a new Groovy version.

I planned on creating both Alpine and non-Alpine images since that seems to
be the current practice.  But we need to get GROOVY-7906
<https://issues.apache.org/jira/browse/GROOVY-7906> resolved for the Alpine
images to work.

I'm concerned about whether it'd be legal for us to distribute the Oracle
JDK with Groovy.  I saw this article on the topic: http://blog.takipi.com/
running-java-on-docker-youre-breaking-the-law/.  I don't speak legalize
though.  I haven't seen anyone else (Jruby, etc) publishing Oracle JDK, and
Oracle has never published Docker images that were not OpenJDK.  The only
images floating out there have been community-created.  So for the time
being, I don't plan to publish Oracle based images.

Once we think these look good, I'll move the repo over to groovy org in
Github and we'll get them published to Docker Hub.  Maybe we could also ask
Apache Infra to get them added to https://hub.docker.com/u/apache/, I
haven't decided.  What do you think?

On Fri, Sep 9, 2016 at 11:19 PM, Corum, Michael  wrote:

> Not related to Groovy as much.  We’ve never been able to get OpenJDK (7 or
> 8) to work properly with Oracle JDBC drivers on Alpine.  Always have to use
> Oracle JDK and in the research we did, we found others with the same issues.
>
> *Michael Corum *
>
> VP, Technical Architecture Solutions
>
>
>
> *RGA Reinsurance Company*
>
> *16600 Swingley Ridge Road*
>
> *Chesterfield, Missouri 6301701706*
>
> *T* 636.736.7066 <(636)%20736-7066>
>
> *www.rgare.com <http://www.rgare.com>*
>
>
>
> From: Guillaume Laforge 
> Reply-To: "users@groovy.apache.org" 
> Date: Friday, September 9, 2016 at 10:16 PM
> To: "users@groovy.apache.org" 
> Subject: Re: Groovy Docker images
>
> Out of curiosity, what's the problem with OpenJDK?
> Is it related to Groovy or not at all?
>
> On Sat, Sep 10, 2016 at 5:09 AM, Corum, Michael  wrote:
>
>>
>>
>>- Either one
>>- Alpine – I suspect others will want other options though
>>- Would most definitely prefer Oracle but I assume other would want
>>OpenJDK as well.  For my purposes OpenJDK just doesn’t work at all.
>>
>> *Michael Corum *
>>
>> VP, Technical Architecture Solutions
>>
>>
>>
>> *RGA Reinsurance Company*
>>
>> *16600 Swingley Ridge Road*
>>
>> *Chesterfield, Missouri 6301701706*
>>
>> *T* 636.736.7066 <(636)%20736-7066>
>>
>> *www.rgare.com <http://www.rgare.com>*
>>
>>
>>
>> From: Keegan Witt 
>> Reply-To: "users@groovy.apache.org" 
>> Date: Friday, September 9, 2016 at 9:48 PM
>> To: "users@groovy.apache.org" 
>> Subject: Groovy Docker images
>>
>> I was thinking of putting together some Docker images for Groovy, with
>> the idea they might be useful to base Grails, Gradle, etc images on and
>> wondered people's opinions on a few things.
>>
>>- Should I install Groovy manually in somewhere like /opt?  Or use
>>SDKMAN?
>>- Should I have images based on Alpine and Debian? Alpine only?
>>- I presume OpenJDK images are fine as bases?  Any reason we'd need
>>an Oracle based image too?
>>
>> Thoughts?
>>
>> -Keegan
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>

Re: Groovy Docker images

[Keegan Witt]

What I did as a workaround for GROOVY-7906 was install bash change the
shebangs to be /bin/bash.  Any reason we shouldn't do that in the Groovy
source?

On Sun, Dec 11, 2016 at 1:24 AM, Keegan Witt  wrote:

> Sorry for the long turnaround on this.  I've got some basic Dockerfiles
> put together: https://github.com/keeganwitt/groovy-docker.  Please let me
> know what I can improve.  One thing I might do is template out the
> Dockerfiles similar to what Ruby did
> <https://github.com/docker-library/ruby> to make it easier to publish
> images when there's a new Groovy version.
>
> I planned on creating both Alpine and non-Alpine images since that seems
> to be the current practice.  But we need to get GROOVY-7906
> <https://issues.apache.org/jira/browse/GROOVY-7906> resolved for the
> Alpine images to work.
>
> I'm concerned about whether it'd be legal for us to distribute the Oracle
> JDK with Groovy.  I saw this article on the topic: http://blog.takipi.com/
> running-java-on-docker-youre-breaking-the-law/.  I don't speak legalize
> though.  I haven't seen anyone else (Jruby, etc) publishing Oracle JDK, and
> Oracle has never published Docker images that were not OpenJDK.  The only
> images floating out there have been community-created.  So for the time
> being, I don't plan to publish Oracle based images.
>
> Once we think these look good, I'll move the repo over to groovy org in
> Github and we'll get them published to Docker Hub.  Maybe we could also ask
> Apache Infra to get them added to https://hub.docker.com/u/apache/, I
> haven't decided.  What do you think?
>
> On Fri, Sep 9, 2016 at 11:19 PM, Corum, Michael  wrote:
>
>> Not related to Groovy as much.  We’ve never been able to get OpenJDK (7
>> or 8) to work properly with Oracle JDBC drivers on Alpine.  Always have to
>> use Oracle JDK and in the research we did, we found others with the same
>> issues.
>>
>> *Michael Corum *
>>
>> VP, Technical Architecture Solutions
>>
>>
>>
>> *RGA Reinsurance Company*
>>
>> *16600 Swingley Ridge Road*
>>
>> *Chesterfield, Missouri 6301701706*
>>
>> *T* 636.736.7066 <(636)%20736-7066>
>>
>> *www.rgare.com <http://www.rgare.com>*
>>
>>
>>
>> From: Guillaume Laforge 
>> Reply-To: "users@groovy.apache.org" 
>> Date: Friday, September 9, 2016 at 10:16 PM
>> To: "users@groovy.apache.org" 
>> Subject: Re: Groovy Docker images
>>
>> Out of curiosity, what's the problem with OpenJDK?
>> Is it related to Groovy or not at all?
>>
>> On Sat, Sep 10, 2016 at 5:09 AM, Corum, Michael  wrote:
>>
>>>
>>>
>>>- Either one
>>>- Alpine – I suspect others will want other options though
>>>- Would most definitely prefer Oracle but I assume other would want
>>>OpenJDK as well.  For my purposes OpenJDK just doesn’t work at all.
>>>
>>> *Michael Corum *
>>>
>>> VP, Technical Architecture Solutions
>>>
>>>
>>>
>>> *RGA Reinsurance Company*
>>>
>>> *16600 Swingley Ridge Road*
>>>
>>> *Chesterfield, Missouri 6301701706*
>>>
>>> *T* 636.736.7066 <(636)%20736-7066>
>>>
>>> *www.rgare.com <http://www.rgare.com>*
>>>
>>>
>>>
>>> From: Keegan Witt 
>>> Reply-To: "users@groovy.apache.org" 
>>> Date: Friday, September 9, 2016 at 9:48 PM
>>> To: "users@groovy.apache.org" 
>>> Subject: Groovy Docker images
>>>
>>> I was thinking of putting together some Docker images for Groovy, with
>>> the idea they might be useful to base Grails, Gradle, etc images on and
>>> wondered people's opinions on a few things.
>>>
>>>- Should I install Groovy manually in somewhere like /opt?  Or use
>>>SDKMAN?
>>>- Should I have images based on Alpine and Debian? Alpine only?
>>>- I presume OpenJDK images are fine as bases?  Any reason we'd need
>>>an Oracle based image too?
>>>
>>> Thoughts?
>>>
>>> -Keegan
>>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>
>
>

Re: Groovy Docker images

[Keegan Witt]

Thanks for the feedback, Thibault.  I've responded in-line.

   - Might be better not to start groovysh, might be mentioned in
   Dockerfile comments instead
   - It's just a default to be run when the user does "docker run", they
  can specify an alternative command to run if they choose (see my grape
  example further down).  Ruby, JRuby, and Python all do this, and it's
  mentioned in Docker's best practices
  
<https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#cmd>
  .
   - Add Dockerfile comments, at least a link to the repo containing the
   dockerfiles
  - Did you mean a link to the Docker Hub page?  If not, what comments
  do you think would be helpful in the Dockerfiles?
   - Add a LICENSE file to the github repo
  - Good catch.  Done.
   - Add a travis job to the github repo that verifies the Dockerfiles
  - Yea, I intend to change the readme to link to the Docker Hub page
  (once published) and a Travis job, as you've suggested.  Build automation
  is something I have to work out yet, goes with the templating work I
  mentioned.
  - Provide one sample image on top of those images with some hello
   world application
   - Usage is pretty straightforward, but I could do that.  It probably
  should be in a separate repo though, don't you think?  Also any
suggestions
  on a good sample?  I was thinking something not compiled Groovy, because
  for that you'd just run with Java Docker image, no need for Groovy on
  path.  Maybe a script of some kind.
   - Check if grapes can be run from containers
  - Grape seemed to work, was there a particular problem you were
  concerned about?

$ docker run -it --rm --name groovy groovy:jre8-latest

Dec 11, 2016 9:37:40 AM java.util.prefs.FileSystemPreferences$1 run

INFO: Created user preferences directory.

Groovy Shell (2.4.7, JVM: 1.8.0_111)

Type ':help' or ':h' for help.




--

groovy:000> groovy.grape.Grape.grab(group:'org.springframework',
module:'spring', version:'2.5.6')

===> null


$ docker run -it --rm --name groovy groovy:jre8-latest grape install
'org.springframework' 'spring' '2.5.6'

:: loading settings :: url = jar:file:/opt/groovy/lib/ivy-
2.4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml

:: resolving dependencies :: caller#all-caller;working72

confs: [default]

found org.springframework#spring;2.5.6 in jcenter

found commons-logging#commons-logging;1.1.1 in jcenter

downloading https://jcenter.bintray.com/org/springframework/spring/2.
5.6/spring-2.5.6.jar ...

[SUCCESSFUL ] org.springframework#spring;2.5.6!spring.jar (2741ms)

downloading https://jcenter.bintray.com/commons-logging/commons-
logging/1.1.1/commons-logging-1.1.1.jar ...

[SUCCESSFUL ] commons-logging#commons-logging;1.1.1!commons-logging.jar
(719ms)


On Sun, Dec 11, 2016 at 3:32 AM, Thibault Kruse 
wrote:

> Some minor comments:
> - might be better not to start groovysh, might be mentioned in
> Dockerfile comments instead
> - Add Dockerfile comments, at least a link to the repo containing the
> dockerfiles
> - Add a LICENSE file to the github repo
> - Add a travis job to the github repo that verifies the Dockerfiles
> - check if grapes can be run from containers
> - Provide one sample image on top of those images with some hello
> world application
>
>
> On Sun, Dec 11, 2016 at 3:24 PM, Keegan Witt  wrote:
> > Sorry for the long turnaround on this.  I've got some basic Dockerfiles
> put
> > together: https://github.com/keeganwitt/groovy-docker.  Please let me
> know
> > what I can improve.  One thing I might do is template out the Dockerfiles
> > similar to what Ruby did to make it easier to publish images when
> there's a
> > new Groovy version.
> >
> > I planned on creating both Alpine and non-Alpine images since that seems
> to
> > be the current practice.  But we need to get GROOVY-7906 resolved for the
> > Alpine images to work.
> >
> > I'm concerned about whether it'd be legal for us to distribute the Oracle
> > JDK with Groovy.  I saw this article on the topic:
> > http://blog.takipi.com/running-java-on-docker-youre-breaking-the-law/.
> I
> > don't speak legalize though.  I haven't seen anyone else (Jruby, etc)
> > publishing Oracle JDK, and Oracle has never published Docker images that
> > were not OpenJDK.  The only images floating out there have been
> > community-created.  So for the time being, I

Re: Groovy Docker images

[Keegan Witt]

It would be nice to be able to offer an Alpine based image.  There's quite
a size difference.  The non-Alpine image is 388.4 MB while the Alpine image
is 189 MB, less than 1/2 the size.

Do you think we should mount ~/.groovy as a volume?  Might be useful for
~/.groovy/grapes in particular.

On Sun, Dec 11, 2016 at 5:12 AM, Keegan Witt  wrote:

> Thanks for the feedback, Thibault.  I've responded in-line.
>
>- Might be better not to start groovysh, might be mentioned in
>Dockerfile comments instead
>- It's just a default to be run when the user does "docker run", they
>   can specify an alternative command to run if they choose (see my grape
>   example further down).  Ruby, JRuby, and Python all do this, and it's
>   mentioned in Docker's best practices
>   
> <https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#cmd>
>   .
>- Add Dockerfile comments, at least a link to the repo containing the
>dockerfiles
>   - Did you mean a link to the Docker Hub page?  If not, what
>   comments do you think would be helpful in the Dockerfiles?
>- Add a LICENSE file to the github repo
>   - Good catch.  Done.
>- Add a travis job to the github repo that verifies the Dockerfiles
>   - Yea, I intend to change the readme to link to the Docker Hub page
>   (once published) and a Travis job, as you've suggested.  Build 
> automation
>   is something I have to work out yet, goes with the templating work I
>   mentioned.
>   - Provide one sample image on top of those images with some hello
>world application
>- Usage is pretty straightforward, but I could do that.  It probably
>   should be in a separate repo though, don't you think?  Also any 
> suggestions
>   on a good sample?  I was thinking something not compiled Groovy, because
>   for that you'd just run with Java Docker image, no need for Groovy on
>   path.  Maybe a script of some kind.
>- Check if grapes can be run from containers
>   - Grape seemed to work, was there a particular problem you were
>   concerned about?
>
> $ docker run -it --rm --name groovy groovy:jre8-latest
>
> Dec 11, 2016 9:37:40 AM java.util.prefs.FileSystemPreferences$1 run
>
> INFO: Created user preferences directory.
>
> Groovy Shell (2.4.7, JVM: 1.8.0_111)
>
> Type ':help' or ':h' for help.
>
> 
> 
> 
> --
>
> groovy:000> groovy.grape.Grape.grab(group:'org.springframework',
> module:'spring', version:'2.5.6')
>
> ===> null
>
>
> $ docker run -it --rm --name groovy groovy:jre8-latest grape install
> 'org.springframework' 'spring' '2.5.6'
>
> :: loading settings :: url = jar:file:/opt/groovy/lib/ivy-2
> .4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
>
> :: resolving dependencies :: caller#all-caller;working72
>
> confs: [default]
>
> found org.springframework#spring;2.5.6 in jcenter
>
> found commons-logging#commons-logging;1.1.1 in jcenter
>
> downloading https://jcenter.bintray.com/org/springframework/spring/2.5.
> 6/spring-2.5.6.jar ...
>
> [SUCCESSFUL ] org.springframework#spring;2.5.6!spring.jar (2741ms)
>
> downloading https://jcenter.bintray.com/commons-logging/commons-logging/
> 1.1.1/commons-logging-1.1.1.jar ...
>
> [SUCCESSFUL ] 
> commons-logging#commons-logging;1.1.1!commons-logging.jar
> (719ms)
>
>
> On Sun, Dec 11, 2016 at 3:32 AM, Thibault Kruse 
> wrote:
>
>> Some minor comments:
>> - might be better not to start groovysh, might be mentioned in
>> Dockerfile comments instead
>> - Add Dockerfile comments, at least a link to the repo containing the
>> dockerfiles
>> - Add a LICENSE file to the github repo
>> - Add a travis job to the github repo that verifies the Dockerfiles
>> - check if grapes can be run from containers
>> - Provide one sample image on top of those images with some hello
>> world application
>>
>>
>> On Sun, Dec 11, 2016 at 3:24 PM, Keegan Witt 
>> wrote:
>> > Sorry for the long turnaround on this.  I've got some basic Dockerfiles
>> put
>> > together: https://github.com/keeganwitt/groovy-docker.  Please let me
>> know
>> > what I can improve.  One thing I might do is template out the
>> Dockerfiles
>> > similar to what Ruby did to make 

Re: Looking for testers & feedback: new Groovy binaries for Windows

[Keegan Witt]

I was on the right track with the GroovyStarter idea.  The problem is,
Launch4j doesn't do variable expansion in cmdLine (as you can see in head.c
<https://sourceforge.net/p/launch4j/git/ci/master/tree/head_src/head.c>,
and as mentioned here
<https://sourceforge.net/p/launch4j/discussion/332684/thread/b41c22bc/>).
I opened an issue <https://sourceforge.net/p/launch4j/bugs/162/> to request
this, but until the feature is available, it kills the idea of using
Launch4J I think.


On Mon, Oct 17, 2016 at 10:53 PM, Keegan Witt  wrote:

> Thanks Paco,
> It looks like it's related to @GrabConfig(systemClassLoader=true), I'm
> looking into it.
>
> -Keegan
>
> On Mon, Oct 17, 2016 at 12:20 PM, Paco Zarate 
> wrote:
>
>> Hey Keegan,
>> Looks like there is a problem with Grapes and the .exe files:
>> I am attaching the test code (a sqlite example from SO)
>>
>> When i use the groovy.bat i got:
>> c:\Data\Samples\Groovy\sqlite>groovy.bat samplesqlite.groovy
>> id=1, name= leo
>> id=2, name= yui
>>
>> When i use the groovy.exe i got this error:
>> c:\Data\Samples\Groovy\sqlite>groovy.exe samplesqlite.groovy
>> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
>> failed:
>> General error during conversion: No suitable ClassLoader found for grab
>>
>> java.lang.RuntimeException: No suitable ClassLoader found for grab
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
>> Method)
>> at sun.reflect.NativeConstructorAccessorImpl.newInstance(Native
>> ConstructorAccessorImpl.java:62)
>> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(De
>> legatingConstructorAccessorImpl.java:45)
>> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>> at org.codehaus.groovy.reflection.CachedConstructor.invoke(Cach
>> edConstructor.java:83)
>> at org.codehaus.groovy.runtime.callsite.ConstructorSite$Constru
>> ctorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
>> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCa
>> llConstructor(CallSiteArray.java:60)
>> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCo
>> nstructor(AbstractCallSite.java:235)
>> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCo
>> nstructor(AbstractCallSite.java:247)
>> at groovy.grape.GrapeIvy.chooseClassLoader(GrapeIvy.groovy:184)
>> at groovy.grape.GrapeIvy$chooseClassLoader.callCurrent(Unknown
>> Source)
>> at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCa
>> llCurrent(CallSiteArray.java:52)
>> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCu
>> rrent(AbstractCallSite.java:154)
>> at org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCu
>> rrent(AbstractCallSite.java:166)
>> at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:251)
>> at groovy.grape.Grape.grab(Grape.java:167)
>> at groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotati
>> onTransformation.java:378)
>> at org.codehaus.groovy.transform.ASTTransformationVisitor$3.cal
>> l(ASTTransformationVisitor.java:321)
>> at org.codehaus.groovy.control.CompilationUnit.applyToSourceUni
>> ts(CompilationUnit.java:931)
>> at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation
>> (CompilationUnit.java:593)
>> at org.codehaus.groovy.control.CompilationUnit.processPhaseOper
>> ations(CompilationUnit.java:569)
>> at org.codehaus.groovy.control.CompilationUnit.compile(Compilat
>> ionUnit.java:546)
>> at groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader
>> .java:298)
>> at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.j
>> ava:268)
>> at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
>> at groovy.lang.GroovyShell.run(GroovyShell.java:517)
>>     at groovy.lang.GroovyShell.run(GroovyShell.java:507)
>> at groovy.ui.GroovyMain.processOnce(GroovyMain.java:653)
>> at groovy.ui.GroovyMain.run(GroovyMain.java:384)
>> at groovy.ui.GroovyMain.process(GroovyMain.java:370)
>> at groovy.ui.GroovyMain.processArgs(GroovyMain.java:129)
>> at groovy.ui.GroovyMain.main(GroovyMain.java:109)
>>
>> 1 error
>>
>> Thanks!
>> Paco.
>>
>>
>>
>> On Tue, Oct 11, 2016 at 4:50 PM, Keegan Witt 
>> wrote:
>>
>>> Well there's the bat file in bin.  Might be good to keep it there at
>>> least initially, as a transition though.
>>>
>>> -Keegan
>>>
>>>

Re: Groovy Docker images

[Keegan Witt]

I'm confused. Isn't Azul a commercial JRE? What's that have to do with
Groovy in Docker? Did you reply to wrong thread?

As a side note, @jbaruch gave a talk at Codemash a shirt while ago that
reminded me I should pin the versions of dependencies I'm installing with
apk on the alpine versions. I'll do that after the conference.

-Keegan

On Jan 11, 2017 10:12 PM, "Gerald Wiltse"  wrote:

> If you have questions about Azul that you can't seem to figure out online,
> the Azul Product Director is the organizer of my local JUG and I have a
> dialog with him.  I'd be happy to get him involved if you think it will
> help.  Just let me know.
>
> Regards,
> Jerry
>
> Gerald R. Wiltse
> jerrywil...@gmail.com
>
>
> On Tue, Dec 13, 2016 at 8:16 AM, Thibault Kruse 
> wrote:
>
>> By comments I mean what is in the readme. Dockerfiles get copy pasted
>> without attached readme, so they should be self commenting.
>>
>> A minimalist server example may be nice. Can be in the same repo as a
>> means of documentation, I think.
>>
>> For grapes I was worried about download location not writable.
>>
>>
>>
>> On Dec 11, 2016 19:12, "Keegan Witt"  wrote:
>>
>> Thanks for the feedback, Thibault.  I've responded in-line.
>>
>>- Might be better not to start groovysh, might be mentioned in
>>Dockerfile comments instead
>>- It's just a default to be run when the user does "docker run", they
>>   can specify an alternative command to run if they choose (see my grape
>>   example further down).  Ruby, JRuby, and Python all do this, and it's
>>   mentioned in Docker's best practices
>>   
>> <https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#cmd>
>>   .
>>- Add Dockerfile comments, at least a link to the repo containing the
>>dockerfiles
>>- Did you mean a link to the Docker Hub page?  If not, what comments
>>   do you think would be helpful in the Dockerfiles?
>>- Add a LICENSE file to the github repo
>>- Good catch.  Done.
>>- Add a travis job to the github repo that verifies the Dockerfiles
>>- Yea, I intend to change the readme to link to the Docker Hub page
>>   (once published) and a Travis job, as you've suggested.  Build 
>> automation
>>   is something I have to work out yet, goes with the templating work I
>>   mentioned.
>>   - Provide one sample image on top of those images with some hello
>>world application
>>- Usage is pretty straightforward, but I could do that.  It probably
>>   should be in a separate repo though, don't you think?  Also any 
>> suggestions
>>   on a good sample?  I was thinking something not compiled Groovy, 
>> because
>>   for that you'd just run with Java Docker image, no need for Groovy on
>>   path.  Maybe a script of some kind.
>>- Check if grapes can be run from containers
>>   - Grape seemed to work, was there a particular problem you were
>>   concerned about?
>>
>> $ docker run -it --rm --name groovy groovy:jre8-latest
>>
>> Dec 11, 2016 9:37:40 AM java.util.prefs.FileSystemPreferences$1 run
>>
>> INFO: Created user preferences directory.
>>
>> Groovy Shell (2.4.7, JVM: 1.8.0_111)
>>
>> Type ':help' or ':h' for help.
>>
>> 
>> 
>> 
>> --
>>
>> groovy:000> groovy.grape.Grape.grab(group:'org.springframework',
>> module:'spring', version:'2.5.6')
>>
>> ===> null
>>
>>
>> $ docker run -it --rm --name groovy groovy:jre8-latest grape install
>> 'org.springframework' 'spring' '2.5.6'
>>
>> :: loading settings :: url = jar:file:/opt/groovy/lib/ivy-2
>> .4.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
>>
>> :: resolving dependencies :: caller#all-caller;working72
>>
>> confs: [default]
>>
>> found org.springframework#spring;2.5.6 in jcenter
>>
>> found commons-logging#commons-logging;1.1.1 in jcenter
>>
>> downloading https://jcenter.bintray.com/org/springframework/spring/2.5.6
>> /spring-2.5.6.jar ...
>>
>> [SUCCESSFUL ] org.springframework#spring;2.5.6!spring.jar
>> (274

Re: Groovy Docker images

[Keegan Witt]

Ah, gotcha.  You were talking about which JDK to include in the image.  I
could include images based on Zulu in addition to OpenJDK images if it'd be
helpful (it looks like they are based on OpenJDK so there shouldn't be the
same legal issues Oracle JDK has).  I'm not sure what the differences are
though.  Michael, I don't suppose you know if Zulu has the same issues you
encountered with OpenJDK?

On Thu, Jan 19, 2017 at 2:06 AM, Gerald Wiltse 
wrote:

> Hi Keegan,
>
> It's a bit late and I see you've been moving forward, but here's a
> response to your question.
>
> I'm not an expert on the differences, but Azul has Zing and Zulu.  Both
> appear to be free to use and distribute for OSS.  Here are two relevant
> links:
>
> https://www.azul.com/products/product-overview/
>
> https://www.azul.com/zing-oss-open-source-developer-access/
>
> I don't know enough to make a distinct recommendation about a JDK, so I
> would encourage anyone on the core team who has experience with licensing
> and related factors and any opinions to share to speak out now.
>
> What would be disappointing would be for you to finalize and distribute
> docker images, only to have people point out serious issues in your choice
> of JDK after the fact. That still might happen, but in my opinion, you did
> the right thing by bringing it up now. Kudos and thanks for the effort here!
>
> Regards,
> Jerry
>
> Gerald R. Wiltse
> jerrywil...@gmail.com
>
>
> On Fri, Jan 13, 2017 at 11:03 AM, Keegan Witt 
> wrote:
>
>> I'm confused. Isn't Azul a commercial JRE? What's that have to do with
>> Groovy in Docker? Did you reply to wrong thread?
>>
>> As a side note, @jbaruch gave a talk at Codemash a shirt while ago that
>> reminded me I should pin the versions of dependencies I'm installing with
>> apk on the alpine versions. I'll do that after the conference.
>>
>> -Keegan
>>
>> On Jan 11, 2017 10:12 PM, "Gerald Wiltse"  wrote:
>>
>>> If you have questions about Azul that you can't seem to figure out
>>> online, the Azul Product Director is the organizer of my local JUG and I
>>> have a dialog with him.  I'd be happy to get him involved if you think it
>>> will help.  Just let me know.
>>>
>>> Regards,
>>> Jerry
>>>
>>> Gerald R. Wiltse
>>> jerrywil...@gmail.com
>>>
>>>
>>> On Tue, Dec 13, 2016 at 8:16 AM, Thibault Kruse <
>>> tibokr...@googlemail.com> wrote:
>>>
>>>> By comments I mean what is in the readme. Dockerfiles get copy pasted
>>>> without attached readme, so they should be self commenting.
>>>>
>>>> A minimalist server example may be nice. Can be in the same repo as a
>>>> means of documentation, I think.
>>>>
>>>> For grapes I was worried about download location not writable.
>>>>
>>>>
>>>>
>>>> On Dec 11, 2016 19:12, "Keegan Witt"  wrote:
>>>>
>>>> Thanks for the feedback, Thibault.  I've responded in-line.
>>>>
>>>>- Might be better not to start groovysh, might be mentioned in
>>>>Dockerfile comments instead
>>>>- It's just a default to be run when the user does "docker run",
>>>>   they can specify an alternative command to run if they choose (see 
>>>> my grape
>>>>   example further down).  Ruby, JRuby, and Python all do this, and it's
>>>>   mentioned in Docker's best practices
>>>>   
>>>> <https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#cmd>
>>>>   .
>>>>- Add Dockerfile comments, at least a link to the repo containing
>>>>the dockerfiles
>>>>- Did you mean a link to the Docker Hub page?  If not, what
>>>>   comments do you think would be helpful in the Dockerfiles?
>>>>- Add a LICENSE file to the github repo
>>>>- Good catch.  Done.
>>>>- Add a travis job to the github repo that verifies the Dockerfiles
>>>>- Yea, I intend to change the readme to link to the Docker Hub page
>>>>   (once published) and a Travis job, as you've suggested.  Build 
>>>> automation
>>>>   is something I have to work out yet, goes with the templating work I
>>>>   mentioned.
>>>>   - Provide one sample image on

2.4.8 Windows Installer

[Keegan Witt]

The Windows installer for Groovy 2.4.8 is now available:
https://dl.bintray.com/groovy/Distributions/groovy-2.4.8-installer.exe.

Re: New Gant release

[Keegan Witt]

Hi Russel,
I use Sonatype to publish GMavenPlus.  They have instructions here
http://central.sonatype.org/pages/ossrh-guide.html. It automatically syncs
with Maven Central. Would that be simpler?

-Keegan

On Feb 12, 2017 9:26 AM, "Russel Winder"  wrote:

> There were a couple of bugfixes in Gant that needed releasing. Also it
> has been 20 months since the last release. Given the build changes, the
> Groovy version changes, and ditching Java 6 support, I went for a minor
> release rather than a bugfix release. So we now have 1.10.0.
>
> Now the problem: The last release was in the Codehaus era, which has
> now sadly (but also splendidly given the now Apache connection for
> Groovy) demised. This means I need to find the JCenter route to Maven
> Central. Schalk Cronjé did some work a while back trying to get the
> Bintray and Artifactory plugins working, so there is groundwork but no
> working system.
>
> I tweeted to see if Schalk and possibly Baruch Sadogursky could give me
> a hand. If anyone else has JCenter and Maven Central skills for
> deploying a release, please do wander over to   https://github.com/Gant
> /Gant  and take a peek.
>
> --
> Russel.
> 
> =
> Dr Russel Winder  t: +44 20 7585 2200   voip:
> sip:russel.win...@ekiga.net
> 41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

Official Docker Groovy images

[Keegan Witt]

Official Docker images of Groovy are now available:
https://hub.docker.com/_/groovy/.  Enjoy!  And let me know any issues you
encounter (either reach out directly or report an issue on GitHub
).

-Keegan

Re: Official Docker Groovy images

[Keegan Witt]

I'm preparing to update for 2.4.9 and am considering two significant
changes to the initial image.  First, to create a volume to prevent Grape
caches from being put into downstream images (PR #6
), and using a user other
than root for the container (PR #7
).  I'm pretty sure I'm
going to do #6, should be pretty safe.  But I'm still weighing #7.  I wanna
get that decided this week so that we pick something and stick with it, to
avoid breaking anything later.  Please weigh in if you have any opinion.

-Keegan

On Wed, Mar 1, 2017 at 3:20 AM, Guillaume Laforge 
wrote:

> Well done, Keegan!
>
> On Wed, Mar 1, 2017 at 8:12 AM, Daniel Sun 
> wrote:
>
>> Nice!
>>
>>
>>
>> --
>> View this message in context: http://groovy.329449.n5.nabble
>> .com/Official-Docker-Groovy-images-tp5738848p5738851.html
>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>

Re: Official Docker Groovy images

[Keegan Witt]

Sorry, I should have clarified the term.  By "official", I mean the way
Docker team uses the term (which you can read more about here
<https://docs.docker.com/docker-hub/official_repos/>).  Short version is
that the upstream project is OK with them being in Docker Hub, they've been
reviewed by Docker team for best practices, Docker team does security
checks on the images, and helps make sure security patches get applied
quickly, and are generally a good choice for those looking for an image
with the software they're after.

It doesn't mean they're endorsed by ASF, and not even that they're
necessarily strongly affiliated with the upstream project.  In my mind,
they sit in the same place as the Windows installer; kinda official since
it's maintained by someone on the Groovy team, but also kinda unofficial
since it's a convenience binary not strictly following ASF standards.

Make sense?

-Keegan

On Thu, Mar 2, 2017 at 9:03 AM, Cédric Champeau 
wrote:

> Good job Keegan!
>
> Just nitpicking, but what does make those images official? Are they
> endorsed by the ASF?
>
> 2017-03-02 1:37 GMT+01:00 Keegan Witt :
>
>> I'm preparing to update for 2.4.9 and am considering two significant
>> changes to the initial image.  First, to create a volume to prevent Grape
>> caches from being put into downstream images (PR #6
>> <https://github.com/groovy/docker-groovy/pull/6>), and using a user
>> other than root for the container (PR #7
>> <https://github.com/groovy/docker-groovy/pull/7>).  I'm pretty sure I'm
>> going to do #6, should be pretty safe.  But I'm still weighing #7.  I wanna
>> get that decided this week so that we pick something and stick with it, to
>> avoid breaking anything later.  Please weigh in if you have any opinion.
>>
>> -Keegan
>>
>> On Wed, Mar 1, 2017 at 3:20 AM, Guillaume Laforge 
>> wrote:
>>
>>> Well done, Keegan!
>>>
>>> On Wed, Mar 1, 2017 at 8:12 AM, Daniel Sun 
>>> wrote:
>>>
>>>> Nice!
>>>>
>>>>
>>>>
>>>> --
>>>> View this message in context: http://groovy.329449.n5.nabble
>>>> .com/Official-Docker-Groovy-images-tp5738848p5738851.html
>>>> Sent from the Groovy Users mailing list archive at Nabble.com.
>>>>
>>>
>>>
>>>
>>> --
>>> Guillaume Laforge
>>> Apache Groovy committer & PMC Vice-President
>>> Developer Advocate @ Google Cloud Platform
>>>
>>> Blog: http://glaforge.appspot.com/
>>> Social: @glaforge <http://twitter.com/glaforge> / Google+
>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>
>>
>>
>

[ANNOUNCE] Groovy 2.4.10 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.4.10 is available from the usual place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.4.10-installer.exe


-Keegan

Gradle Docker image available

[Keegan Witt]

FYI, I've contributed Docker Gradle images into the official images:
https://hub.docker.com/_/gradle/.  Enjoy!

-Keegan

Re: [ANNOUNCE] Groovy 2.4.10 Windows Installer Released

[Keegan Witt]

I think I had built this without the large strings patch, so I rebuilt
today just to be sure.  It also seemed to clear PATH out, but I haven't
seen that happen with this new binary so far.

On Mon, Mar 20, 2017 at 1:50 AM, Paul King  wrote:

> That was quick! Nice work! :-)
>
> On Mon, Mar 20, 2017 at 1:47 PM, Keegan Witt  wrote:
> > The Windows installer for Groovy 2.4.10 is available from the usual
> place:
> > https://bintray.com/groovy/Distributions/download_file?
> file_path=groovy-2.4.10-installer.exe
> >
> >
> > -Keegan
>

Re: Maven coordinates going forward

[Keegan Witt]

I'm +1 on Maven coordinate change.  That should be fairly low impact.

I agree package renames should be taken on a case-by-case basis.  Offhand,
the two biggest things that come to mind are custom ASTs, and the
compilation bits.  For the former, I'd think it shouldn't be any worse than
the groovy.transforms move.  For the latter, it might make sense to wait to
rename that package until the compilation is decoupled from the core.

On Tue, Mar 28, 2017 at 9:36 AM, Jochen Theodorou  wrote:

>
> On 27.03.2017 22:14, Wilson MacGyver wrote:
>
>> as I recall, there are also rules about jigsaw not allowing same package
>> path from multiple modules. It's not till java 9, but that maybe a
>> concern.
>>
>
> That is right, yes... it is only a problem for Groovy as named or
> automatic module though. As long as Groovy stays in the
> classpath/annonymous module variant, there is no such problem with multiple
> jars, as long as the overlapping package names are all from the
> classpath/annonymous module
>
>
> bye Jochen
>

Re: Maven coordinates going forward

[Keegan Witt]

That's a good point.  It could cause some issues for Groovy as a transitive
dependency, but doing a global exclude in Maven is fairly easy to do.

On Tue, Mar 28, 2017 at 1:42 PM, Cédric Champeau 
wrote:

> One thing one has to consider when changing Maven coordinates, is...
> Maven. Despite being a build tool, it does a fairly poor job when
> coordinates change. In particular, think of conflict resolution. What
> should it decide if A depends on org.codehaus.groovy:2.4.10 and B depends
> on org.apache.groovy:groovy-all:3.0? Maven is pretty bad at this. We have
> strategies to deal with this in Gradle (dependency substitution), but it
> will imply that projects could find different artifacts on classpath in the
> future, for a dependency on Groovy.
>
> That said, I'm open to changing the coordinates. I would do this for the
> "breaking" version of Groovy, whatever it is, but not before. Which means,
> the same version as the one we change package names.
>
> 2017-03-28 19:03 GMT+02:00 Keegan Witt :
>
>> I'm +1 on Maven coordinate change.  That should be fairly low impact.
>>
>> I agree package renames should be taken on a case-by-case basis.
>> Offhand, the two biggest things that come to mind are custom ASTs, and the
>> compilation bits.  For the former, I'd think it shouldn't be any worse than
>> the groovy.transforms move.  For the latter, it might make sense to wait to
>> rename that package until the compilation is decoupled from the core.
>>
>> On Tue, Mar 28, 2017 at 9:36 AM, Jochen Theodorou 
>> wrote:
>>
>>>
>>> On 27.03.2017 22:14, Wilson MacGyver wrote:
>>>
>>>> as I recall, there are also rules about jigsaw not allowing same package
>>>> path from multiple modules. It's not till java 9, but that maybe a
>>>> concern.
>>>>
>>>
>>> That is right, yes... it is only a problem for Groovy as named or
>>> automatic module though. As long as Groovy stays in the
>>> classpath/annonymous module variant, there is no such problem with multiple
>>> jars, as long as the overlapping package names are all from the
>>> classpath/annonymous module
>>>
>>>
>>> bye Jochen
>>>
>>
>>
>

[ANNOUNCE] Groovy 2.4.11 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.4.11 is available from the usual place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.4.11-installer.exe
.

-Keegan

[ANNOUNCE] Groovy 2.5.0-alpha-1 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.5.0-alpha-1 is available from the usual
place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.0-alpha-1-installer.exe
.

-Keegan

Re: Using Groovy with JavaFX

[Keegan Witt]

For the benefit of those reading the list: I responded to the related
GMavenPlus issue  that was
raised.

-Keegan


On Fri, Jun 2, 2017 at 1:44 PM, dewful  wrote:

> Hi -
>
> I am new to the Groovy community.
>
> I am using Maven 3.3.9 + Spock Testing Framework + GMavenPlus (1.5) +
> Groovy
> 2.4 + JavaFX with Java8 on OSX 11.10. I'm trying to get mvn test to execute
> successfully, but the groovy tests I have are not finding the javafx
> classes. The errors are like:
>
> java.lang.ClassNotFoundException: javafx.scene.control.MenuBar
>
> I believe the issue I'm having is due to java8 now by default includes the
> javafx jar on the classpath
> (/Library/Java/JavaVirtualMachines/jdk1.8.0_60.jdk/Contents/
> Home/jre/lib/ext
> on OSX, which is below java home), it isn't an external dependency in
> maven.
> However, when running groovy with javafx, groovy doesn't seem to have the
> javafx jar on its path.
>
> Other projects like https://github.com/groovyfx-project/groovyfx seem to
> need groovy to specifically specify the jar on the command line using '-cp
> '. Also, in gradle I found what I think is a similar bug:
> https://stackoverflow.com/questions/32570973/gradle-groovy-
> compilation-cannot-find-javafx-classes-in-tests.
>
> Groovy seems to say that jars added in a ~/.groovy/lib folder will be added
> to the classpath, although putting the jfxrt.jar in there didn't seem to
> have an effect.
>
> The main question is whats the best way to get groovy to find the javafx
> dependency jars so mvn test can succeed? Any suggestions on where maven
> would need this?
>
> Thank you!
>
>
>
> --
> View this message in context: http://groovy.329449.n5.nabble
> .com/Using-Groovy-with-JavaFX-tp5741460.html
> Sent from the Groovy Users mailing list archive at Nabble.com.
>

[ANNOUNCE] Groovy 2.5.0-beta-1 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.5.0-beta-1 is available from the usual
place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.0-beta-1-installer.exe
.

GMavenPlus 1.6 Released

[Keegan Witt]

GMavenPlus 1.6 has been released to Sonatype OSS
 and should appear in
Maven Central  shortly.  Besides the usual minor
tweaks, this release
 includes

*Bugs*
[38 ] - Compilation doesn't
allow indy back far enough (thanks for pointing this out Pascal Schumacher!)


*Enhancements*
[36 ] - Allow script files
to be executed as filenames as well as URLs (see Significant changes of
note for an example)

[41 ] - Verify Groovy
version supports target bytecode (See Potentially breaking changes for a
description)

[46 ] - Remove
scriptExtensions config option

[58 ] - IntelliJ improperly
adding stub directories to sources

[61 ] - You can now skip
Groovydoc generation with new skipGroovyDoc property (Thanks rvenutolo
!)

[45 ] - GROOVY-7423 (JEP 118
) Support (requires Groovy 2.5.0-alpha-1
or newer and enabled with new parameters boolean property)

*Potentially breaking changes*

Issues 46 will break your build if you are using .  But
the fix is simple, just the delete the configuration option and GMavenPlus
will automatically do the right thing.

Issue 41 will break your build if you were passing an invalid target
bytecode.  GMavenPlus will no longer allow Groovy to silently default to
1.4 or 1.5.  It will verify that the bytecode is supported by your Groovy
version (that is, the option exists in
org.codehaus.groovy.control.CompilerConfiguration),
and fail if it isn't.

Issue 58 will require renaming goals testGenerateStubs to generateTestStubs
and testCompile to compileTests.  IntelliJ has hard-coded the goal names in
their plugin, and these names will make IntelliJ work with both GMaven and
GMavenPlus.

In order to support using the latest Maven plugins (and to make GMavenPlus
easier to maintain), GMavenPlus now requires Java 6 or newer and Maven
3.0.1 or newer (previously was Java 5 or newer and Maven 2.2.1 or newer).

*Significant changes of note*

You can now use this syntax for executing scripts

${project.basedir}/src/main/resources/groovyScripts/helloWorld.
groovy

in addition to the original style of

file:///${project.basedir}/src/main/resources/groovy
Scripts/helloWorld.groovy

*Getting help / reporting bugs*

As usual, let me know of any bugs you encounter either on our user mailing
list (http://groups.google.com/group/gmavenplus), Github issues (
https://github.com/groovy/GMavenPlus/issues), or Slack (
https://groovy-community.slack.com/messages/C2SLAV9FY/).

Enjoy!

-Keegan

[ANNOUNCE] Groovy 2.5.0-beta-2 and 2.6.0-alpha-1 Windows Installers Released

[Keegan Witt]

The Windows installer for Groovy 2.5.0-beta-2 and 2.6.0-alpha-1 are
available from the usual places:
https://bintray.com/groovy/Distributions/download_file?
file_path=groovy-2.5.0-beta-1-installer.exe
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.6.0-alpha-1-installer.exe

Re: [ANNOUNCE] Groovy 2.5.0-beta-2 and 2.6.0-alpha-1 Windows Installers Released

[Keegan Witt]

Just realized I gave the wrong link to 2.5.0-beta-2, should be
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.0-beta-2-installer.exe
.

On Mon, Oct 9, 2017 at 2:00 AM, Paul King  wrote:

> Nice, thanks!
>
> On Mon, Oct 9, 2017 at 1:35 PM, Keegan Witt  wrote:
>
>> The Windows installer for Groovy 2.5.0-beta-2 and 2.6.0-alpha-1 are
>> available from the usual places:
>> https://bintray.com/groovy/Distributions/download_file?file_
>> path=groovy-2.5.0-beta-1-installer.exe
>> https://bintray.com/groovy/Distributions/download_file?file_
>> path=groovy-2.6.0-alpha-1-installer.exe
>>
>
>

[ANNOUNCE] Groovy 2.6.0-alpha-2 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.6.0-alpha-2 is available from the usual
place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.6.0-alpha-2-installer.exe

[ANNOUNCE] Groovy 2.4.13 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.4.13 is available from the usual place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.4.13-installer.exe

-Keegan

[ANNOUNCE] Groovy 3.0.0-alpha-1 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 3.0.0-alpha-1 is available from the usual
place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-alpha-1-installer.exe

Notable for this release, Spock is not included since it doesn't work with
Groovy 3 yet.

Re: [ANNOUNCE] Groovy 3.0.0-alpha-1 Windows Installer Released

[Keegan Witt]

1.1-groovy-2.4 is what I've been including, but I got this error while
testing the installation

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
failed:
Could not instantiate global transform class
org.spockframework.compiler.SpockTransform specified at
jar:file:/C:/Program%20Files%20(x86)/Groovy/Groovy-3.0.0/lib/spock-core-1.1-groovy-2.4.jar!/META-INF/services/org.codehaus.groovy.transform.ASTTransformation
because of exception
org.spockframework.util.IncompatibleGroovyVersionException: The Spock
compiler plugin cannot execute because Spock 1.1.0-groovy-2.4 is not
compatible with Groovy 3.0.0-alpha-1. For more information, see
http://versioninfo.spockframework.org
Spock artifact:
file:/C:/Program%20Files%20(x86)/Groovy/Groovy-3.0.0/lib/spock-core-1.1-groovy-2.4.jar
Groovy artifact:
file:/C:/Program%20Files%20(x86)/Groovy/Groovy-3.0.0/lib/groovy-3.0.0-alpha-1.jar

The latest (20171211.142320-34) 1.2 snapshot does seem to work though.  I
guess I'll repackage 3.0 with it.

-Keegan

On Wed, Dec 20, 2017 at 3:29 AM, Russel Winder  wrote:

> On Wed, 2017-12-20 at 15:56 +1000, Paul King wrote:
> > You can use a SNAPSHOT version of Spock, e.g. 1.1-groovy-2.4-SNAPSHOT
> > or
> > 1.2-groovy-2.4-SNAPSHOT
>
> 1.1-groovy-2.4 is released, no need to use a snapshot.
>
> 1.2-groovy-2.4-SNAPSHOT doesn't seem to have made it to Maven Central
> yet.
>
> --
> Russel.
> ===
> Dr Russel Winder  t: +44 20 7585 2200
> 41 Buckmaster Roadm: +44 7770 465 077
> London SW11 1EN, UK   w: www.russel.org.uk
>

Re: [ANNOUNCE] Groovy 3.0.0-alpha-1 Windows Installer Released

[Keegan Witt]

Published.  Thanks for the suggestion.

-Keegan

On Wed, Dec 20, 2017 at 8:35 PM, Keegan Witt  wrote:

> 1.1-groovy-2.4 is what I've been including, but I got this error while
> testing the installation
>
> org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
> failed:
> Could not instantiate global transform class 
> org.spockframework.compiler.SpockTransform
> specified at jar:file:/C:/Program%20Files%20(x86)/Groovy/Groovy-3.0.0/
> lib/spock-core-1.1-groovy-2.4.jar!/META-INF/services/org.
> codehaus.groovy.transform.ASTTransformation  because of exception
> org.spockframework.util.IncompatibleGroovyVersionException: The Spock
> compiler plugin cannot execute because Spock 1.1.0-groovy-2.4 is not
> compatible with Groovy 3.0.0-alpha-1. For more information, see
> http://versioninfo.spockframework.org
> Spock artifact: file:/C:/Program%20Files%20(x86)/Groovy/Groovy-3.0.0/lib/
> spock-core-1.1-groovy-2.4.jar
> Groovy artifact: file:/C:/Program%20Files%20(x86)/Groovy/Groovy-3.0.0/lib/
> groovy-3.0.0-alpha-1.jar
>
> The latest (20171211.142320-34) 1.2 snapshot does seem to work though.  I
> guess I'll repackage 3.0 with it.
>
> -Keegan
>
> On Wed, Dec 20, 2017 at 3:29 AM, Russel Winder 
> wrote:
>
>> On Wed, 2017-12-20 at 15:56 +1000, Paul King wrote:
>> > You can use a SNAPSHOT version of Spock, e.g. 1.1-groovy-2.4-SNAPSHOT
>> > or
>> > 1.2-groovy-2.4-SNAPSHOT
>>
>> 1.1-groovy-2.4 is released, no need to use a snapshot.
>>
>> 1.2-groovy-2.4-SNAPSHOT doesn't seem to have made it to Maven Central
>> yet.
>>
>> --
>> Russel.
>> ===
>> Dr Russel Winder  t: +44 20 7585 2200
>> 41 Buckmaster Roadm: +44 7770 465 077
>> London SW11 1EN, UK   w: www.russel.org.uk
>>
>
>

[ANNOUNCE] Groovy 2.4.14 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 2.4.14 is available from the usual place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.4.14-installer.exe

-Keegan

[ANNOUNCE] Groovy 2.4.15 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 2.4.15 is available from the usual place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.4.15-installer.exe

-Keegan

[ANNOUNCE] Groovy 2.5.0-beta-3 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 2.5.0-beta-3 is available from the usual
place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.0-beta-3-installer.exe

-Keegan

[ANNOUNCE] Groovy 2.6.0-alpha-3 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 2.6.0-alpha-3 is available from the usual
place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.6.0-alpha-3-installer.exe

-Keegan

[ANNOUNCE] Groovy 2.5.0-rc-1 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 2.5.0-rc-1 is available from the usual
place:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.5.0-rc-1-installer

-Keegan

[ANNOUNCE] Groovy 3.0.0-alpha-2 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 3.0.0-alpha-2 is available from the usual
place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-alpha-2-installer.exe

-Keegan

GMavenPlus 1.6.1 Released

[Keegan Witt]

GMavenPlus 1.6.1 has been released to Sonatype OSS
 and should appear in
Maven Central  shortly.  Besides the usual minor
tweaks, this release includes

*Bugs*



[93 ] - Fixed that was
logging Groovy version as not supporting config script if config script
file didn't exist
[84 ] - Fixed NPE when
calling mojo without Groovy dependency
[NA] - Fixed that was logging compile classpath instead of test classpath
during test GroovyDoc generation

*Enhancements*

None

*Potentially breaking changes*

None
*Getting help / reporting bugs*

As usual, let me know of any bugs you encounter either on our user mailing
list (http://groups.google.com/group/gmavenplus), Github issues (
https://github.com/groovy/GMavenPlus/issues), or Slack (
https://groovy-community.slack.com/messages/C2SLAV9FY/).

Enjoy!

Re: Java survey, show your Groovy love ;-)

[Keegan Witt]

It's unfortunate it won't let you choose multiple primary application
languages, I think it's often an app is a mix of Java and Groovy.

On Fri, May 11, 2018 at 3:31 AM, Guillaume Laforge 
wrote:

> I just spotted this Java survey:
> https://snykteam.typeform.com/to/V4LOUZ
>
> They donate money to Devoxx4Kids if they have enough respondents.
>
> You can mention your preferred programming language (Groovy!), build tool
> (Gradle!), web framework (Grails!), testing tool (Spock!), code quality
> tool (Codenarc!), etc :-)
>
> In case you want to show your love ;-)
>
> Guillaume
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge 
>

[ANNOUNCE] Groovy 2.5.0-rc-3 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.5.0-rc-3 is available from the usual
place:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.5.0-rc-3-installer

-Keegan

[ANNOUNCE] Groovy 2.5.0 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 2.5.0 is available from the usual place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.0-installer.exe

-Keegan

[ANNOUNCE] Groovy 3.0.0-alpha-3 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 3.0.0-alpha-3 is available from the usual
place:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-3.0.0-alpha-3-installer
.

[ANNOUNCE] Groovy 2.6.0-alpha-4 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.6.0-alpha-4 is available from the usual
place:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.6.0-alpha-4-installer
.

[ANNOUNCE] Groovy 2.5.1 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.5.1 is available from the usual place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.1-installer.exe
.

-Keegan

[ANNOUNCE] Groovy 2.5.2 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 2.5.2 is available from the usual place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.2-installer.exe
.

GMavenPlus 1.6.2 Released

[Keegan Witt]

GMavenPlus 1.6.2 has been released to Sonatype OSS
 and should appear in
Maven Central  shortly.
Bugs

   - Support for Java 10 bytecode (#104
   )
   - Support for Java 11 bytecode (#106
   )
   - Fixed that could error saying no Groovy dependency when it shouldn't
   because no Groovy sources exist (ef3a3d5
   

   ).

Enhancements

None
Potentially breaking changes

None
Notes

None

[ANNOUNCE] Groovy 2.5.3 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 2.5.3 is available from the usual place:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.5.3-installer
.

Re: GMavenPlus 1.6.2 Released

[Keegan Witt]

Sorry, one point of clarification on a copy/paste error: the Java 10 and 11
bytecode changes are enhancements, not bugs.

On Sun, Oct 14, 2018 at 4:28 PM Keegan Witt  wrote:

> GMavenPlus 1.6.2 has been released to Sonatype OSS
> <https://oss.sonatype.org/content/repositories/public/> and should appear
> in Maven Central <http://search.maven.org/> shortly.
> Bugs
>
>- Support for Java 10 bytecode (#104
><https://github.com/groovy/GMavenPlus/issues/104>)
>- Support for Java 11 bytecode (#106
><https://github.com/groovy/GMavenPlus/issues/106>)
>- Fixed that could error saying no Groovy dependency when it shouldn't
>because no Groovy sources exist (ef3a3d5
>
> <https://github.com/groovy/GMavenPlus/commit/ef3a3d51dae4d13ab12821e679d594a8bf468179>
>).
>
> Enhancements
>
> None
> Potentially breaking changes
>
> None
> Notes
>
> None
>

[ANNOUNCE] Groovy 2.5.4 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 2.5.4 is available from the usual place:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.5.4-installer
.

[ANNOUNCE] Groovy 2.4.16 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 2.4.16 is available from the usual place:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.4.16-installer
.

-Keegan

[ANNOUNCE] Groovy 2.5.5 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.5.5 is available from the usual place:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.5.5-installer
.

-Keegan

[ANNOUNCE] Groovy 3.0.0-alpha-4 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 3.0.0-alpha-4 is available from the usual
place:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-alpha-4-installer.exe
.

Note this installer doesn't include Spock since there isn't a Spock release
compatible with Groovy 3.0.

-Keegan

Re: [ANNOUNCE] Groovy 3.0.0-alpha-4 Windows Installer Released

[Keegan Witt]

I didn't see any groovy-3.0 snapshots in the snapshot repo:
https://oss.sonatype.org/content/repositories/snapshots/org/spockframework/spock-core/.
Did they move them somewhere else?  Or they just haven't pushed any
snapshots yet?

On Sun, Dec 30, 2018 at 9:31 PM Paul King  wrote:

> Thanks Keegan!
>
> For anyone interested, you should be able to use snapshot versions of
> Spock with Groovy 3.0.0.
>
>
> On Mon, Dec 31, 2018 at 11:39 AM Keegan Witt  wrote:
>
>> The Windows installer for Groovy 3.0.0-alpha-4 is available from the
>> usual place:
>> https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-alpha-4-installer.exe
>> .
>>
>> Note this installer doesn't include Spock since there isn't a Spock
>> release compatible with Groovy 3.0.
>>
>> -Keegan
>>
>

Groovy on ppc64le, arm64v8, and s390x

[Keegan Witt]

I'm trying to fix some errors I have in the Docker Groovy
 images on the ppc64le, arm64v8,
and s390x architectures. I don't personally have any experience working
with these architectures. Here are the errors I get

*powerpc64le
*
Dec 29, 2018 6:10:09 PM
org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
WARNING: Module [groovy-datetime] - Unable to load extension class
[org.apache.groovy.datetime.extensions.DateTimeExtensions]
Dec 29, 2018 6:10:09 PM
org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
WARNING: Module [groovy-datetime] - Unable to load extension class
[org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:110)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128)
Caused by: java.lang.UnsatisfiedLinkError: Could not load library. Reasons:
[no jansi in java.library.path, /tmp/libjansi-64-6177151729256195035.so:
Error relocating /tmp/libjansi-64-6177151729256195035.so: unsupported
relocation type 7 (Possible cause: can't load AMD 64-bit .so on a Power PC
64-bit platform)]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
at
org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:195)
at
groovyjarjarpicocli.CommandLine$Help$Ansi.isJansiConsoleInstalled(CommandLine.java:9362)
at
groovyjarjarpicocli.CommandLine$Help$Ansi.ansiPossible(CommandLine.java:9358)
at
groovyjarjarpicocli.CommandLine$Help$Ansi.enabled(CommandLine.java:9376)
at
groovyjarjarpicocli.CommandLine$Help$Ansi$Text.toString(CommandLine.java:9728)
at java.lang.String.valueOf(String.java:2849)
at java.io.PrintStream.println(PrintStream.java:821)
at
groovyjarjarpicocli.CommandLine.printVersionHelp(CommandLine.java:1563)
at
groovyjarjarpicocli.CommandLine.printHelpIfRequested(CommandLine.java:1027)
at
groovyjarjarpicocli.CommandLine.printHelpIfRequested(CommandLine.java:995)
at groovy.ui.GroovyMain.processArgs(GroovyMain.java:130)
at groovy.ui.GroovyMain.main(GroovyMain.java:116)
... 6 more

*arm64v8
*
Dec 30, 2018 2:32:22 AM
org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
WARNING: Module [groovy-datetime] - Unable to load extension class
[org.apache.groovy.datetime.extensions.DateTimeExtensions]
Dec 30, 2018 2:32:23 AM
org.codehaus.groovy.runtime.m12n.MetaInfExtensionModule newModule
WARNING: Module [groovy-datetime] - Unable to load extension class
[org.apache.groovy.datetime.extensions.DateTimeStaticExtensions]
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.codehaus.groovy.tools.GroovyStarter.rootLoader(GroovyStarter.java:110)
at org.codehaus.groovy.tools.GroovyStarter.main(GroovyStarter.java:128)
Caused by: java.lang.UnsatisfiedLinkError: Could not load library. Reasons:
[no jansi in java.library.path, /tmp/libjansi-64-6661390371961894243.so:
Error relocating /tmp/libjansi-64-6661390371961894243.so: unsupported
relocation type 7 (Possible cause: can't load AMD 64-bit .so on a
AARCH64-bit platform)]
at org.fusesource.hawtjni.runtime.Library.doLoad(Library.java:182)
at org.fusesource.hawtjni.runtime.Library.load(Library.java:140)
at org.fusesource.jansi.internal.CLibrary.(CLibrary.java:42)
at
org.fusesource.jansi.AnsiConsole.wrapOutputStream(AnsiConsole.java:48)
at org.fusesource.jansi.AnsiConsole.(AnsiConsole.java:38)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:195)
at
groovyjarjarpicocli.CommandLine$Help$Ansi.isJansiConsoleInstalled(CommandLine.java:9362)
at
groovyjarjarpicocli.CommandLine$Help$Ansi.ansiPossible(CommandLine.java:9358)
at
groovyjarjarpicocli.CommandLine$Help$Ansi.enabled(CommandLine.java:

[ANNOUNCE] Groovy 2.5.6 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.5.6 is available from the usual place:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.5.6-installer
.

-Keegan

New Groovy Windows installer

[Keegan Witt]

I'm working on a new installer 
for Windows using WIX  to create an MSI installer,
which should be more robust for things like altering environment variables
and make it easier to do corporate installations.

I'm a total noob when it comes to Windows Installer and WIX, so I'm sure
I've done some dumb things, but I hacked together a basic working installer
this weekend.  I've put the initial version of the installer here
.
Your feedback is appreciated.

Some things I'm still thinking about or working on:

   - The start menu shortcuts for documentation don't go into a subfolder,
   I'm not sure why.
   - Heat will generate new GUIDs for the binaries and docs folders every
   time the project is built -- I'm not sure if that's the correct thing to do.
   - Would you ever want to set GROOVY_HOME without adding to PATH?  Or add
   to PATH without setting GROOVY_HOME?  Currently the installer groups these
   together in a single feature.
   - We should use registry entries to remember which features the user
   selected to install, so those are automatically selected during upgrades.
   - Desktop shortcuts.
   - Quick launch shortcuts.  I don't think people use these much anymore,
   but I can throw them in -- maybe disabled by default?
   - Should I create an exe version of the installer as well as the msi?

-Keegan

Groovy file associations on Windows

[Keegan Witt]

In addition to removing projects that are no longer developed from the
Groovy Windows installer (Gpars, Gaelyk, Scriptom, EasyB, Gant, GMock), I'm
considering removing the exe files from groovy-native-launcher
.  These haven't been
compiled in quite a while and are just another thing to maintain.  As I see
it, there are two primary benefits these provide.

   1. Provide a way to create file associations so you can double click a
   Groovy file, or run myFile.groovy instead of groovy myFile.groovy.
   2. Hide the command window when launching GroovyConsole.

For #2, I can work around this with a VBScript file (or NirCmd).  #1
doesn't have a good way to solve other than the current native binary
solution since Launch4J doesn't support variable expansion
.  My question is, do many
folks need this functionality?  It's something I've never personally used.
Please weigh in with your thoughts.

-Keegan

Re: New Groovy Windows installer

[Keegan Witt]

Oh, one more item

   - Is 200 the installer version I should use?


On Sun, Feb 10, 2019 at 9:24 PM Keegan Witt  wrote:

> I'm working on a new installer <https://github.com/keeganwitt/groovy-wix>
> for Windows using WIX <http://wixtoolset.org/> to create an MSI
> installer, which should be more robust for things like altering environment
> variables and make it easier to do corporate installations.
>
> I'm a total noob when it comes to Windows Installer and WIX, so I'm sure
> I've done some dumb things, but I hacked together a basic working installer
> this weekend.  I've put the initial version of the installer here
> <https://www.dropbox.com/sh/w2giakqb2jcc82e/AAB_gqvCvzOU1t-2dRlV4yBoa?dl=0>.
> Your feedback is appreciated.
>
> Some things I'm still thinking about or working on:
>
>- The start menu shortcuts for documentation don't go into a
>subfolder, I'm not sure why.
>- Heat will generate new GUIDs for the binaries and docs folders every
>time the project is built -- I'm not sure if that's the correct thing to 
> do.
>- Would you ever want to set GROOVY_HOME without adding to PATH?  Or
>add to PATH without setting GROOVY_HOME?  Currently the installer groups
>these together in a single feature.
>- We should use registry entries to remember which features the user
>selected to install, so those are automatically selected during upgrades.
>- Desktop shortcuts.
>- Quick launch shortcuts.  I don't think people use these much
>anymore, but I can throw them in -- maybe disabled by default?
>- Should I create an exe version of the installer as well as the msi?
>
> -Keegan
>

Re: New Groovy Windows installer

[Keegan Witt]

Oh, and one important note for those playing with the new installer:
uninstall the NSIS based Groovy first and make sure GROOVY_HOME,
%PROGRAM_FILES%\Groovy, and PATH are free from references to the old
installation before proceeding.

On Sun, Feb 10, 2019 at 9:26 PM Keegan Witt  wrote:
>
> Oh, one more item
>
> Is 200 the installer version I should use?
>
>
> On Sun, Feb 10, 2019 at 9:24 PM Keegan Witt  wrote:
>>
>> I'm working on a new installer for Windows using WIX to create an MSI 
>> installer, which should be more robust for things like altering environment 
>> variables and make it easier to do corporate installations.
>>
>> I'm a total noob when it comes to Windows Installer and WIX, so I'm sure 
>> I've done some dumb things, but I hacked together a basic working installer 
>> this weekend.  I've put the initial version of the installer here.  Your 
>> feedback is appreciated.
>>
>> Some things I'm still thinking about or working on:
>>
>> The start menu shortcuts for documentation don't go into a subfolder, I'm 
>> not sure why.
>> Heat will generate new GUIDs for the binaries and docs folders every time 
>> the project is built -- I'm not sure if that's the correct thing to do.
>> Would you ever want to set GROOVY_HOME without adding to PATH?  Or add to 
>> PATH without setting GROOVY_HOME?  Currently the installer groups these 
>> together in a single feature.
>> We should use registry entries to remember which features the user selected 
>> to install, so those are automatically selected during upgrades.
>> Desktop shortcuts.
>> Quick launch shortcuts.  I don't think people use these much anymore, but I 
>> can throw them in -- maybe disabled by default?
>> Should I create an exe version of the installer as well as the msi?
>>
>> -Keegan

Re: Groovy file associations on Windows

[Keegan Witt]

Do folks using it really need it to be in the lib directory with all the
other jars? Or could they just use Grapes/Grab?

If it's truly helpful, I can keep it.  I'm just wondering if it's overkill.

On Mon, Feb 11, 2019, 2:19 AM Paul King  I'd be inclined to keep GPars in the mix for now. It isn't actively
> maintained but is still very useful in its current form and I hope to put
> some time into it at some stage.
>
> Cheers, Paul.
>
>
> On Mon, Feb 11, 2019 at 12:24 PM Keegan Witt  wrote:
>
>> In addition to removing projects that are no longer developed from the
>> Groovy Windows installer (Gpars, Gaelyk, Scriptom, EasyB, Gant, GMock), I'm
>> considering removing the exe files from groovy-native-launcher
>> <https://github.com/groovy/groovy-native-launcher>.  These haven't been
>> compiled in quite a while and are just another thing to maintain.  As I see
>> it, there are two primary benefits these provide.
>>
>>1. Provide a way to create file associations so you can double click
>>a Groovy file, or run myFile.groovy instead of groovy myFile.groovy.
>>2. Hide the command window when launching GroovyConsole.
>>
>> For #2, I can work around this with a VBScript file (or NirCmd).  #1
>> doesn't have a good way to solve other than the current native binary
>> solution since Launch4J doesn't support variable expansion
>> <https://sourceforge.net/p/launch4j/bugs/162/>.  My question is, do many
>> folks need this functionality?  It's something I've never personally used.
>> Please weigh in with your thoughts.
>>
>> -Keegan
>>
>

Re: Groovy file associations on Windows

[Keegan Witt]

I hear you.  But where do you draw the line?

There are a lot of popular libraries we also could include besides Gpars
and Scriptom (e.g. Geb , Spock
, groovy-wslite
, http-builder-ng
, Gru
, gstorm
, dru ,
GroovyServ , Gaiden
, shoogr
, etc) -- and those are just some ones
with commits in the last year that aren't for building or hosting web
stuff.  There are many more besides this.  And because it's just a bundle
including whatever the latest versions were at the time of a Groovy release
for a specific selection of projects (and not a project like sdkman),
there's no way to mix & match versions or upgrade independent of a Groovy
release.
Although I guess if we want the installer to include a bunch of different
library options, maybe we could have the installer fetch the requested jars
from the internet, I suppose.  Though I'm not sure how the file GUIDs would
work if we did that.  MSIs I've seen that do that (like have .NET Framework
as a dependency) usually invoke a separate MSI for each dependency.

-Keegan


On Tue, Feb 12, 2019 at 2:13 AM Daniel Sun  wrote:

> Yep. e.g. banks usually does not allow employees access Internet. Luckily
> some of them will setup maven server.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

Re: New Groovy Windows installer

[Keegan Witt]

Update: The documentation directory on the start menu actually does
get created -- Windows 10 just doesn't show subdirectories on start
menu folders like previous versions of Windows did.

On Sun, Feb 10, 2019 at 11:07 PM Keegan Witt  wrote:
>
> Oh, and one important note for those playing with the new installer:
> uninstall the NSIS based Groovy first and make sure GROOVY_HOME,
> %PROGRAM_FILES%\Groovy, and PATH are free from references to the old
> installation before proceeding.
>
> On Sun, Feb 10, 2019 at 9:26 PM Keegan Witt  wrote:
> >
> > Oh, one more item
> >
> > Is 200 the installer version I should use?
> >
> >
> > On Sun, Feb 10, 2019 at 9:24 PM Keegan Witt  wrote:
> >>
> >> I'm working on a new installer for Windows using WIX to create an MSI 
> >> installer, which should be more robust for things like altering 
> >> environment variables and make it easier to do corporate installations.
> >>
> >> I'm a total noob when it comes to Windows Installer and WIX, so I'm sure 
> >> I've done some dumb things, but I hacked together a basic working 
> >> installer this weekend.  I've put the initial version of the installer 
> >> here.  Your feedback is appreciated.
> >>
> >> Some things I'm still thinking about or working on:
> >>
> >> The start menu shortcuts for documentation don't go into a subfolder, I'm 
> >> not sure why.
> >> Heat will generate new GUIDs for the binaries and docs folders every time 
> >> the project is built -- I'm not sure if that's the correct thing to do.
> >> Would you ever want to set GROOVY_HOME without adding to PATH?  Or add to 
> >> PATH without setting GROOVY_HOME?  Currently the installer groups these 
> >> together in a single feature.
> >> We should use registry entries to remember which features the user 
> >> selected to install, so those are automatically selected during upgrades.
> >> Desktop shortcuts.
> >> Quick launch shortcuts.  I don't think people use these much anymore, but 
> >> I can throw them in -- maybe disabled by default?
> >> Should I create an exe version of the installer as well as the msi?
> >>
> >> -Keegan

Re: New Groovy Windows installer

[Keegan Witt]

And the Quick Launch toolbar was removed in Windows 7 (although it can
be added back manually), so I think I won't bother with those
shortcuts.  I never noticed it was removed because I never used it.

On Sun, Feb 17, 2019 at 6:56 PM Keegan Witt  wrote:
>
> Update: The documentation directory on the start menu actually does
> get created -- Windows 10 just doesn't show subdirectories on start
> menu folders like previous versions of Windows did.
>
> On Sun, Feb 10, 2019 at 11:07 PM Keegan Witt  wrote:
> >
> > Oh, and one important note for those playing with the new installer:
> > uninstall the NSIS based Groovy first and make sure GROOVY_HOME,
> > %PROGRAM_FILES%\Groovy, and PATH are free from references to the old
> > installation before proceeding.
> >
> > On Sun, Feb 10, 2019 at 9:26 PM Keegan Witt  wrote:
> > >
> > > Oh, one more item
> > >
> > > Is 200 the installer version I should use?
> > >
> > >
> > > On Sun, Feb 10, 2019 at 9:24 PM Keegan Witt  wrote:
> > >>
> > >> I'm working on a new installer for Windows using WIX to create an MSI 
> > >> installer, which should be more robust for things like altering 
> > >> environment variables and make it easier to do corporate installations.
> > >>
> > >> I'm a total noob when it comes to Windows Installer and WIX, so I'm sure 
> > >> I've done some dumb things, but I hacked together a basic working 
> > >> installer this weekend.  I've put the initial version of the installer 
> > >> here.  Your feedback is appreciated.
> > >>
> > >> Some things I'm still thinking about or working on:
> > >>
> > >> The start menu shortcuts for documentation don't go into a subfolder, 
> > >> I'm not sure why.
> > >> Heat will generate new GUIDs for the binaries and docs folders every 
> > >> time the project is built -- I'm not sure if that's the correct thing to 
> > >> do.
> > >> Would you ever want to set GROOVY_HOME without adding to PATH?  Or add 
> > >> to PATH without setting GROOVY_HOME?  Currently the installer groups 
> > >> these together in a single feature.
> > >> We should use registry entries to remember which features the user 
> > >> selected to install, so those are automatically selected during upgrades.
> > >> Desktop shortcuts.
> > >> Quick launch shortcuts.  I don't think people use these much anymore, 
> > >> but I can throw them in -- maybe disabled by default?
> > >> Should I create an exe version of the installer as well as the msi?
> > >>
> > >> -Keegan

Re: Groovy file associations on Windows

[Keegan Witt]

Actually, for Gpars, that's in the Groovy binary zip, so that's
included already.

On Sun, Feb 17, 2019 at 6:42 PM Keegan Witt  wrote:
>
> I hear you.  But where do you draw the line?
>
> There are a lot of popular libraries we also could include besides Gpars and 
> Scriptom (e.g. Geb, Spock, groovy-wslite, http-builder-ng, Gru, gstorm, dru, 
> GroovyServ, Gaiden, shoogr, etc) -- and those are just some ones with commits 
> in the last year that aren't for building or hosting web stuff.  There are 
> many more besides this.  And because it's just a bundle including whatever 
> the latest versions were at the time of a Groovy release for a specific 
> selection of projects (and not a project like sdkman), there's no way to mix 
> & match versions or upgrade independent of a Groovy release.
> Although I guess if we want the installer to include a bunch of different 
> library options, maybe we could have the installer fetch the requested jars 
> from the internet, I suppose.  Though I'm not sure how the file GUIDs would 
> work if we did that.  MSIs I've seen that do that (like have .NET Framework 
> as a dependency) usually invoke a separate MSI for each dependency.
>
> -Keegan
>
>
> On Tue, Feb 12, 2019 at 2:13 AM Daniel Sun  wrote:
>>
>> Yep. e.g. banks usually does not allow employees access Internet. Luckily
>> some of them will setup maven server.
>>
>> Cheers,
>> Daniel.Sun
>>
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html

Re: New Groovy Windows installer

[Keegan Witt]

Yea, I've thought about renaming the repo to groovy-wix-installer for that
reason.

As for multiplatform installers, there is izpack <http://izpack.org/>, but
I thought it best to use a more native installer when doing things like
modifying PATH (from what I saw people were calling VB or Python scripts to
handle that with izpack -- ugly and potentially dangerous).

On Mon, Feb 18, 2019 at 6:46 AM Merlin Beedell 
wrote:

> I was a bit confused, as WIX is a web site design and hosting service:
> www.wix.com.
>
>  But now I see your link, and it is *WiX Toolset* – “The most powerful
> set of tools available to create your Windows installation experience.”
>
> That makes more sense.
>
> Though it’s a shame that a multi-platform Java based installer could not
> be used (if such a thing exists).
>
>
>
> Merlin Beedell
>
> *From:* Keegan Witt 
> *Sent:* 11 February 2019 2:24 AM
> *To:* users@groovy.apache.org
> *Subject:* New Groovy Windows installer
>
>
>
> I'm working on a new installer <https://github.com/keeganwitt/groovy-wix>
> for Windows using WIX <http://wixtoolset.org/> to create an MSI
> installer, which should be more robust for things like altering environment
> variables and make it easier to do corporate installations.
>
>
>
> I'm a total noob when it comes to Windows Installer and WIX, so I'm sure
> I've done some dumb things, but I hacked together a basic working installer
> this weekend.  I've put the initial version of the installer here
> <https://www.dropbox.com/sh/w2giakqb2jcc82e/AAB_gqvCvzOU1t-2dRlV4yBoa?dl=0>.
> Your feedback is appreciated.
>
>
>
> Some things I'm still thinking about or working on:
>
>- The start menu shortcuts for documentation don't go into a
>subfolder, I'm not sure why.
>- Heat will generate new GUIDs for the binaries and docs folders every
>time the project is built -- I'm not sure if that's the correct thing to 
> do.
>- Would you ever want to set GROOVY_HOME without adding to PATH?  Or
>add to PATH without setting GROOVY_HOME?  Currently the installer groups
>these together in a single feature.
>- We should use registry entries to remember which features the user
>selected to install, so those are automatically selected during upgrades.
>- Desktop shortcuts.
>- Quick launch shortcuts.  I don't think people use these much
>anymore, but I can throw them in -- maybe disabled by default?
>- Should I create an exe version of the installer as well as the msi?
>
> -Keegan
>

GMavenPlus 1.6.3 Released

[Keegan Witt]

GMavenPlus 1.6.3 has been released to Sonatype OSS
 and should appear in
Maven Central  shortly.  This release includes

Bugs

None
Enhancements

   - Ability to use Groovy from plugin dependencies (creates a single
   classpath with plugin and project dependencies) (#64
    & #86
   )
   - Support for Java 13 bytecode (#123
   )
   - Log executed scripts (#119
   )
   - Log message from exception cause (#112
   )

Potentially breaking changes

None
Notes

The feature for #64 & #86 is controversial for me.  In my humble opinion, I
think it's usually a sign of bad build practices if you have a need for
this feature.  It's potentially dangerous, as if there are differing
dependency versions between GMavenPlus's dependencies and your project
dependencies, you may have compiled against a version that is different
than expected (and won't match runtime -- watch out for
NoClassDefFoundError).  However, since multiple users have requested this
option, and since the philosophy of this project is to provide the user
with reasonable defaults but full control, I've acquiesced to the request.
The defaults retain the same behavior as the previous release.
*Getting help / reporting bugs*

As usual, let me know of any bugs you encounter either on our user mailing
list (http://groups.google.com/group/gmavenplus), GitHub issues (
https://github.com/groovy/GMavenPlus/issues), or Slack (
https://groovy-community.slack.com/messages/C2SLAV9FY/).

Enjoy!

-Keegan

GMavenPlus 1.7.0 Released

[Keegan Witt]

GMavenPlus 1.7.0 has been released to Sonatype OSS
 and should appear in
Maven Central  shortly.  This release includes

Bugs


   - Fix executing script from URL in Groovy older than 1.7.0 (#131
   )
   - Use unique configuration names for every mojo, so goals don't conflict
   (#120 )

Enhancements

   - Support Java 13 (#122 )

Potentially breaking changes

#120  corrects an
inadvertent breaking change made in 1.6.0 with #31
/#58
. Additionally,
groovydocJavaSources has been renamed to testGroovydocJavaSources for
testGroovydoc.  Here are those changes:
  1.5 1.6 1.7
addStubSources stubsOutputDirectory outputDirectory stubsOutputDirectory
addTestStubSources testStubsOutputDirectory outputDirectory
testStubsOutputDirectory
compileTests/testCompile testOutputDirectory outputDirectory
testOutputDirectory
generateStubs stubsOutputDirectory outputDirectory stubsOutputDirectory
generateTestStubs/testGenerateStubs testStubsOutputDirectory outputDirectory
testStubsOutputDirectory
groovydocTests/testGroovydoc groovydocJavaSources groovydocJavaSources
testGroovydocJavaSources
removeStubs stubsOutputDirectory outputDirectory stubsOutputDirectory
removeTestStubs testStubsOutputDirectory outputDirectory
testStubsOutputDirectory

In addition, unused parameters have been removed:

addSources

   - skipTests
   - testSources

addStubSources

   - skipTests
   - sources
   - testSources

addTestSources

   - outputDirectory
   - skipTests
   - sources

addTestStubSources

   - sources
   - testSources

compile

   - skipTests
   - testSources

compileTests

   - sources

console

   - skipTests

execute

   - skipTests

generateStubs

   - skipTests
   - testSources

generateTestStubs

   - sources

groovydoc

   - skipTests
   - testSources
   - testGroovyDocOutputDirectory

groovydocTests

   - skipTests
   - sources

removeStubs

   - skipTests
   - sources
   - testSources

removeTestStubs

   - sources
   - testSources

shell

   - skipTests

Lastly, addTestStubSources and removeTestStubs now respect the skipTests
flag, for consistency.
Notes

None
*Getting help / reporting bugs*

As usual, let me know of any bugs you encounter either on our user mailing
list , GitHub issues
, or Slack
.

Enjoy!

[ANNOUNCE] Groovy 2.5.7 and 3.0.0-beta-1 Windows Installers Released

[Keegan Witt]

 The Windows installer for Groovy 2.5.7 is now available from Bintray:
https://bintray.com/groovy/Distributions/Windows-Installer/groovy-2.5.7-installer
.

The Windows installer for Groovy 3.0.0-beta-1 is now available from
Bintray:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-beta-1-installer.exe
.

These are also the first releases where I've published a preview of Windows
Installers created with the WiX Toolset.  I invite you to try them out and
provide any feedback you might have.  It's my intention to eventually
replace the current NSIS-based installer with this installer.  I believe it
to be reasonably stable.  I've personally been using these instead of the
NSIS based installer for a while now.  Here are the links to those
installers:
3.0.0-beta-1:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-beta-1+%28preview+installer%29.msi
2.5.7:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.7+%28preview+installer%29.msi

Be aware that you need to fully uninstall the NSIS based Groovy
installation before installing with an MSI installer.

-Keegan

GMavenPlus 1.7.1 Released

[Keegan Witt]

GMavenPlus 1.7.1 has been released to Sonatype OSS
 and should
appear in Maven
Central  shortly.  This release includes

Bugs

   - Fix that Groovy 3.0.0-alpha-5 was actually released as 3.0.0-beta-1 (
   #133 )

Enhancements

   - Support Java preview features (#125
   )
   - New goals to create GroovyDoc jars (#124
   )
   - Use the new "groovy.console.ui.Console" package, if available, fall
   back to "groovy.ui.Console" (#136
   )

Potentially breaking changes

None
Notes

None


*Getting help / reporting bugs*

As usual, let me know of any bugs you encounter either on our user mailing
list , GitHub issues
, or Slack
.

Enjoy!

-Keegan

[ANNOUNCE] Groovy 3.0.0-beta-2 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 3.0.0-beta-2 is now available from
Bintray:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-beta-2-installer.exe
.

I've again included a preview of an msi built with WiX, which I'm seeking
feedback on:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-beta-2+%28preview+installer%29.msi

Be aware that you need to fully uninstall the NSIS based Groovy installation
before installing with an MSI installer.

[ANNOUNCE] Groovy 2.5.8 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 2.5.8 is now available from Bintray:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.8-installer.exe
.

I've again included a preview of an msi built with WiX, which I'm seeking
feedback on:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.8+%28preview+installer%29.msi

Be aware that you need to fully uninstall the NSIS based Groovy
installation before
installing with an MSI installer.

-Keegan

[ANNOUNCE] Groovy 3.0.0-beta-3 Windows Installer Released

[Keegan Witt]

The Windows installer for Groovy 3.0.0-beta-3 is now available from
Bintray:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-beta-3-installer.exe
.

I've again included a preview of an msi built with WiX, which I'm seeking
feedback on:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-beta-3+%28preview+installer%29.msi

Be aware that you need to fully uninstall the NSIS based Groovy
installation before
installing with an MSI installer.

-Keegan

GMavenPlus 1.8.0 Released

[Keegan Witt]

 This was a small release, offering one new feature.  It bumped up the
minor version because it may require you to adjust your POM to upgrade. Bugs

   - None

Enhancements

   - Allow for invocation using only project classpath (#140
   ). This is accomplished
   with PLUGIN_ONLY.

Potentially breaking changes #140


If you were using useSharedClasspath before, you will need to replace it
with new values. In most cases, this would be
usedSharedClasspath includeClasspath
true PROJECT_AND_PLUGIN
false PROJECT_ONLY

Another notable difference is that when using this new configuration
parameter in *compile*, *compileTests*, *generateStubs*, or
*generateTestStubs* goals, now also uses the configurator to add the
project dependencies to the classpath with the plugin's dependencies.
Previously, this only happened in the goals other than the ones mentioned.
Notes

None

*Getting help / reporting bugs*

As usual, let me know of any bugs you encounter either on our user mailing
list , GitHub issues
, or Slack
.

Enjoy!

[ANNOUNCE] Groovy 3.0.0-rc-1 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 3.0.0-rc1 is now available from Bintray:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-rc-1-installer.exe
.

I've again included a preview of an msi built with WiX, which I'm seeking
feedback on:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-rc-1+%28preview+installer%29.msi
.

Be aware that you need to fully uninstall the NSIS based Groovy
installation before
installing with an MSI installer.

-Keegan

GMavenPlus 1.8.1 Released

[Keegan Witt]

GMavenPlus 1.8.1 has been released.  This release includes
Bugs

   - #147  Change sourcesets
   internal storage from HashSet to TreeSet, to avoid unpredictable Groovy
   compiler output.
   - #145  Disable system
   exits by default, to avoid potential thread safety issues.

Enhancements

None
Potentially breaking changes

   - #145  Changes the
   default of not allowing System.exits to allowing them.

Notes

None

*Getting help / reporting bugs*

As usual, let me know of any bugs you encounter either on our user mailing
list , GitHub issues
, or Slack
.

Enjoy!

[ANNOUNCE] Groovy 3.0.0-rc-2 Windows Installer Released

[Keegan Witt]

 The Windows installer for Groovy 3.0.0-rc2 is now available from Bintray:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-rc-2-installer.exe
.

I've again included a preview of an msi built with WiX, which I'm seeking
feedback on:
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-rc-2+%28preview+installer%29.msi
.

Be aware that you need to fully uninstall the NSIS based Groovy
installation before
installing with an MSI installer.

[ANNOUNCE] Groovy 2.5.9 Windows Installers Released

[Keegan Witt]

 The Windows installers for Groovy 2.5.9 are now available from Bintray.
It is available as

   - The original exe installer, built with NSIS:
   
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.9-installer.exe
   - The new msi installer, built with WiX:
   
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.9.msi

Be aware that you need to fully uninstall the NSIS based Groovy
installation before
installing with an MSI installer.

[ANNOUNCE] Groovy 3.0.0-rc-3 Windows Installers Released

[Keegan Witt]

 The Windows installers for Groovy 3.0.0-rc-2 are now available from
Bintray.  It is available as

   - The original exe installer, built with NSIS:
   
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-rc-3-installer.exe
   - The new msi installer, built with WiX:
   
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.0-rc-3.msi

Be aware that you need to fully uninstall the NSIS based Groovy
installation before
installing with an MSI installer.

[ANNOUNCE] Groovy 2.4.18 Windows Installers Released

[Keegan Witt]

 The Windows installers for Groovy 2.4.18 are now available from Bintray.
It is available as

   - The original exe installer, built with NSIS:
   
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.4.18-installer.exe
   - The new msi installer, built with WiX:
   
https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.4.18.msi

Be aware that you need to fully uninstall the NSIS based Groovy
installation before
installing with an MSI installer.