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 <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" <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 <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 <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 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 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 <keeganw...@gmail.com>
>>>>> 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 <keeganw...@gmail.com>
>>>>>> 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 <blackd...@gmx.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Maybe a stupid question... but couldn't we write an exe in Java and
>>>>>>>> compile using gcj. The exe would spawn a new "normal" JVM and do the
>>>>>>>> argument handling. Unlike the C variant there would be more people 
>>>>>>>> able to
>>>>>>>> handle this.
>>>>>>>>
>>>>>>>> bye Jochen
>>>>>>>>
>>>>>>>> On 08.09.2016 11:13, Paul King wrote:
>>>>>>>>
>>>>>>>>> I think there are numerous problems with the argument passing in
>>>>>>>>> the
>>>>>>>>> batch files. That was one of the things that the exe files aimed to
>>>>>>>>> improve on. I must admit to having reservations about the new
>>>>>>>>> approach.
>>>>>>>>> Not so much with the concept but more about relying on the current
>>>>>>>>> bat
>>>>>>>>> files. That said, I am not sure staying with the current approach
>>>>>>>>> is
>>>>>>>>> ideal either.
>>>>>>>>>
>>>>>>>>> Cheers, Paul.
>>>>>>>>>
>>>>>>>>> On Thu, Sep 8, 2016 at 4:57 PM, Paco Zarate <
>>>>>>>>> conta...@nazcasistemas.com
>>>>>>>>> <mailto:conta...@nazcasistemas.com>> wrote:
>>>>>>>>>
>>>>>>>>>     Hello Keegan
>>>>>>>>>     groovy and groovyc are working for me now! thanks!!
>>>>>>>>>
>>>>>>>>>     The bat file seems to have an issue on Windows though:
>>>>>>>>>
>>>>>>>>>     When the JAVA_HOME is not defined, and the PATH has an element
>>>>>>>>> with
>>>>>>>>>     & (ampersand), the groovy invocation seems to try to execute
>>>>>>>>> the
>>>>>>>>>     code after the & (eg. if mysql is installed there is a PATH
>>>>>>>>> defined to
>>>>>>>>>     "c:\Program Files (x86)\MySQL\MySQL Fabric 1.5 & MySQL
>>>>>>>>> Utilities 1.5")
>>>>>>>>>     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 <
>>>>>>>>> keeganw...@gmail.com
>>>>>>>>>     <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
>>>>>>>>>         <keeganw...@gmail.com <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
>>>>>>>>>             <raviteja.lokin...@gmail.com
>>>>>>>>>             <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
>>>>>>>>>                 <conta...@nazcasistemas.com
>>>>>>>>>                 <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 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
>>>>>>>>>                     <keeganw...@gmail.com <mailto:
>>>>>>>>> keeganw...@gmail.com>>
>>>>>>>>>                     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
>>>>>>>>>                         <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
>>>>>>>>>                         begroovy-windows-installer
>>>>>>>>>                         <https://github.com/groovy/gro
>>>>>>>>> ovy-windows-installer> orgroovy-native-launcher
>>>>>>>>>                         <https://github.com/groovy/gro
>>>>>>>>> ovy-native-launcher>).
>>>>>>>>>
>>>>>>>>>                         To make it easy to test, you can download
>>>>>>>>> the
>>>>>>>>>                         compiled binaries from here
>>>>>>>>>                         (https://drive.google.com/fold
>>>>>>>>> erview?id=0B_uOQFeu84v0TDVkS00xeE5yNHc&usp=sharing
>>>>>>>>>                         <https://drive.google.com/fold
>>>>>>>>> erview?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?
>>>>>>>>>                         Runninggroovy.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() andCreateProcess()?
>>>>>>>>>
>>>>>>>>>                         -Keegan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>                 --
>>>>>>>>>                 *Raviteja Lokineni* | Business Intelligence
>>>>>>>>> Developer
>>>>>>>>>                 TD Ameritrade
>>>>>>>>>
>>>>>>>>>                 E: raviteja.lokin...@gmail.com
>>>>>>>>>                 <mailto:raviteja.lokin...@gmail.com>
>>>>>>>>>
>>>>>>>>>                 View Raviteja Lokineni's profile on LinkedIn
>>>>>>>>>                 <http://in.linkedin.com/in/ravitejalokineni>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>

Attachment: samplesqlite.groovy
Description: Binary data

Reply via email to