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 <[email protected]> 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" <[email protected]> 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 <[email protected]>
>> 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 <[email protected]>
>>> 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 <
>>>> [email protected]> 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 <[email protected]>
>>>>> 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 <[email protected]>
>>>>>> 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 <[email protected]>
>>>>>>> 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 <
>>>>>>>>> [email protected]
>>>>>>>>> <mailto:[email protected]>> 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 <
>>>>>>>>> [email protected]
>>>>>>>>> <mailto:[email protected]>> 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
>>>>>>>>> <[email protected] <mailto:[email protected]>>
>>>>>>>>> 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
>>>>>>>>> <[email protected]
>>>>>>>>> <mailto:[email protected]>> 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
>>>>>>>>> <[email protected]
>>>>>>>>> <mailto:[email protected]>> 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
>>>>>>>>> <[email protected] <mailto:
>>>>>>>>> [email protected]>>
>>>>>>>>> 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: [email protected]
>>>>>>>>> <mailto:[email protected]>
>>>>>>>>>
>>>>>>>>> View Raviteja Lokineni's profile on LinkedIn
>>>>>>>>> <http://in.linkedin.com/in/ravitejalokineni>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
samplesqlite.groovy
Description: Binary data
