Re: [ANNOUNCE] Groovy 2.5.12 and 3.0.4 Windows Installers Released

[Paco Zarate]

Thank you Keegan!!

On Fri, May 22, 2020 at 12:07 AM Keegan Witt  wrote:

> New Groovy installers for Windows released:
>
> 2.5.12:
> https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.12.msi
> 3.0.4:
> https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.4.msi
>
> -Keegan
>

Re: [ANNOUNCE] Groovy 2.5.11 and 3.0.3 Windows Installers Released

[Paco Zarate]

Thank you Keegan!

On Fri, Apr 10, 2020 at 7:51 PM Keegan Witt  wrote:

> New Groovy installers for windows released:
>
> 2.5.11:
> https://bintray.com/groovy/Distributions/download_file?file_path=groovy-2.5.11.msi
> 3.0.3:
> https://bintray.com/groovy/Distributions/download_file?file_path=groovy-3.0.3.msi
>
> -Keegan
>
>

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

[Paco Zarate]

Thank you Keegan will give a try of the msi installer this weekend.

On Thu, Jan 23, 2020 at 6:50 PM Keegan Witt  wrote:

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

Re: [ANNOUNCE] Groovy 2.5.5 Windows Installer Released

[Paco Zarate]

Thank you!

On Mon, Dec 24, 2018 at 3:09 PM Remko Popma  wrote:

> Blogged: https://blogs.apache.org/groovy/entry/groovy-2-5-5-windows
>
> Please share on social media.
>
> On Tue, Dec 25, 2018 at 2:24 AM Keegan Witt  wrote:
>
>> 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
>>
>

Re: [ANNOUNCE] Groovy 2.5.4 Windows Installer Released

[Paco Zarate]

Thank you!!

On Mon, Nov 12, 2018 at 5:36 AM Guillaume Laforge 
wrote:

> Tweeted :-)
>
> On Mon, Nov 12, 2018 at 1:08 PM Remko Popma  wrote:
>
>> Blogged: https://blogs.apache.org/groovy/entry/groovy-2-5-4-windows
>>
>> Please share on social media.
>>
>> On Monday, November 12, 2018, Keegan Witt  wrote:
>>
>>> 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
>>> .
>>>
>>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Twitter: @glaforge 
>

Re: [ANNOUNCE] Groovy 2.5.0 Windows Installer Released

[Paco Zarate]

Thank you Keegan!

On Sun, Jun 10, 2018 at 1:27 PM, MG  wrote:

> Thanks Keegan,
> Cheers,
> mg
>
> On 10.06.2018 18:55, Keegan Witt wrote:
>
> 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
>
>
>

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

[Paco Zarate]

Thank you Keegan!

On Tue, Dec 19, 2017 at 4:46 PM, Daniel.Sun  wrote:

> Thank you,  Keegan :-)
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Users-f329450.html
>

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

[Paco Zarate]

thanks Keegan!

On Mon, Oct 9, 2017 at 5:25 PM, Keegan Witt  wrote:

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

Re: Consider statically typed/compiled as default for Groovy 3.0

[Paco Zarate]

I really like this topic.
1) Groovy syntax is incredible readable/maintainable. I take Groovy code
from years ago and I am able to make changes easily. Thank you guys for
this!

2) The dynamic portion of Groovy is interesting but it has some limits:
when you are coding you need to recompile to see a change on a single line.
Is it possible to have a the code recompiled on the fly? Is it possible in
Groovy to step back during the debug? And finally, would be a way to be
debugging Groovy code, hit a breakpoint, modify some already executed code
on the fly, step back and rerun it? I guess all this is more tooling
related than language related, but I would appreciate your opinions.

3) Have you seen the Smalltalk;s Pharo environment? they have visual tools
to access and modify the Smalltalk app internals.  For example, see all the
objects and modify then in the fly, include more code, save the state of
the app (image) and reload it later. It is really interesting and I wonder
if Groovy could use its dynamic nature that way.

4) For the static portion of Groovy: Have you think in the Typescript way
of doing things? They are the "javascript++" but they have been doing it
though transpiling to a very readable javascript. The option I see, would
be to have Groovy generating Java code + maps for debugging. The use case
would be: you work in a Java company, use Groovy to develop and then
deliver to your company very readable Java code. I guess this may be doable
with CompileStatic Groovy code and have a chance to apply too to generate
Android Java code.


On Fri, Oct 13, 2017 at 7:14 AM, Cédric Champeau 
wrote:

> Wise words, Paul. I would also very much prefer to see progress in the
> Java 9 area rather than this, or even the parser. It's much more relevant
> to the future of Groovy IMHO. Because, as the ticket explains, there's
> already ways to enable this feature (even if a bit cumbersome). It's really
> of that importance, then a pull request, accepted through a VOTE, would
> certainly be the fastest way to get this.
>
> 2017-10-13 15:11 GMT+02:00 Paul King :
>
>> I think most committers are also keen on making progress in the
>> directions you describe. Not along the lines of watering down Groovy's
>> dynamic capabilities but certainly in terms of making Groovy's static
>> nature as hassle free as possible to use. Having said that, we have limited
>> resources, so we need to prioritise and do a limited numbers of things well
>> rather than half do lots of things. Most of us have our own long list of
>> technical issues that we think need working on (jdk9 support, new parser,
>> bugs we know of in static type checking, many other features we'd like,
>> etc.), so if you aren't seeing a lot of traction for this idea, it is
>> possibly because we see a big list of things that would be needed to be
>> sorted out to do this well and we are weighing up that list with our
>> already long todo lists.
>>
>> Perhaps we wear our technical hats too much and should put on our
>> marketing hats a bit more - who knows. All I can suggest to you is that
>> Apache Groovy follows the Apache do-ocracy culture. If anyone picks off a
>> small piece of the puzzle and advances it forward, it is likely to
>> progress. But it's not guaranteed, so you are doing the right thing by
>> discussing on the mailing lists. If you still don't get traction, start
>> again with a smaller step.
>>
>> Cheers, Paul.
>>
>> On Fri, Oct 13, 2017 at 6:30 AM, MG  wrote:
>>
>>> blackdrag suggested to move this
>>> https://issues.apache.org/jira/browse/GROOVY-8329
>>> discussion from Jira to this list, so I am replying here:
>>>
>>> I agree with Endre Stølsvik: I think Groovy should strengthen its
>>> language support for statically compiled use, and I agree it should move
>>> towards making statically using it as hassle free as possible.
>>>
>>> I think Endre has already made some good points why this would be a good
>>> idea, so I am just going to add that I am convinced that Groovy would not
>>> be at 3% of the languages used after Java, but at > 30% (basically everyone
>>> that could freely pick a language for commercial projects besides Java
>>> would be using it) if it would fully be the Java++ it in fact is - in my
>>> perception what kept it back was the fact that it "is slow" (true > 10
>>> years back), that it is just "a script language" (never true afaik) - and
>>> that it "is a dynamic language" (no longer true, but...). When I picked
>>> Groovy for the project I work on, I did so despite it was dynamic, not
>>> because of that (the static Groovy compiler that someone in Russia had
>>> built at the time helped in the decision...).
>>>
>>> Being able to be dynamic in a language is a powerful feature, but one
>>> that is needed only in special cases. Otherwise Groovy would already rule
>>> the Java world ;-)
>>>
>>> Being able to have a very simple configscript that qualifies every class
>>> with @CompileStatic is great (http://docs.groovy-lang.org/

Re: Emacs Groovy Mode

[Paco Zarate]

Thanks Russel and Wilfred!

On Mon, May 8, 2017 at 1:45 AM, Russel Winder  wrote:

> Anyone using the Emacs Groovy Mode from https://github.com/Groovy-Emacs
> -Modes/groovy-emacs-modes or MELPA almost certainly needs to take note,
> as I have likely broken your setup.
>
> First apologies for doing this, but there had to be a breaking change
> in order to get progress on all the things that were bugging people,
> and now seemed as good a time as any.
>
> The change is that the old "derived from java-mode, derived from cc-
> mode" mode has been switched from the master branch to the 1.X branch,
> and the new standalone groovy-mode (thanks due to Wilfred Hughes) has
> been switched in from its feature branch to master. I believe MELPA
> will pick up this new mode automatically.
>
> If you have lots of groovy-mode set up based on all the old c-XXX
> variables, this will now do nothing. Those variables were the cc-mode
> ones and are now redundant in the new groovy-mode. There are a slew of
> new variables for setting up the styling required.
>
> If this changes makes you angry and want to string me up, then either:
>
> 1. Use groovy-mode 1.0.1 from MELPA Stable.
> 2. Clone the repository and use the groovy-mode.el from the 1.X branch.
>
> This should then be exactly what you had before.
>
> --
> 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

Re: [ANNOUNCE] Groovy 2.4.11 Windows Installer Released

[Paco Zarate]

Thanks!

On Mon, May 8, 2017 at 7:40 PM, Paul King  wrote:

> Thanks Keegan!
>
> On Tue, May 9, 2017 at 11:02 AM, Keegan Witt  wrote:
>
>> The Windows installer for Groovy 2.4.11 is available from the usual
>> place: https://bintray.com/groovy/Distributions/download_fil
>> e?file_path=groovy-2.4.11-installer.exe.
>>
>> -Keegan
>>
>
>

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

[Paco Zarate]

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

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

[Paco Zarate]

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

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

[Paco Zarate]

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

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

[Paco Zarate]

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

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

[Paco Zarate]

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