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 <conta...@nazcasistemas.com> 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 <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> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >
