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
,
and as mentioned here
).
I opened an issue  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
>>>
>>> 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,
>>>

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

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 > > 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
>> mailto:keeganw...@gmail.com>> 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
>> mailto:keeganw...@gmail.com>> wrote:
>>
>> Hi Paco,
>> Thanks

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

[Jochen Theodorou]

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

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
mailto:keeganw...@gmail.com>> 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
mailto:keeganw...@gmail.com>> 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 issu

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, Paco Zarate <
 conta...@nazcasistemas.com> 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 no

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

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

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

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

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

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

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

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

[Jochen Theodorou]

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.

Thanks,
Raviteja

On Wed, Sep 7, 2016 at 5:45 AM, Paco Zarate
mailto:conta...@nazcasistemas.com>> 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 

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

[Paul King]

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 
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  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.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
>>  or
>> groovy-native-launcher
>> 

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

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

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

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

[Raviteja Lokineni]

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

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
>