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 <[email protected]> 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 <[email protected] >> <mailto:[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] >> <mailto:[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] <mailto:[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] <mailto:[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] >> <mailto:[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] <mailto:[email protected]>> >> wrote: >> >> I started experimenting with launch4j, and have >> put that experiment in this >> repo: https://github.com/keeganwitt/ >> groovy-launch4j >> <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] >> <mailto:[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] >> <mailto:[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]> >> <mailto:[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]> >> <mailto:[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]> >> <mailto:[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]> >> >> <mailto:[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]> >> >> <mailto:[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]> >> <mailto:[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> >> >> <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 >> <https://github.com/groovy/gro >> ovy-windows-installer>> >> orgroovy-native-launcher >> >> <https://github.com/groovy/gro >> ovy-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> >> >> <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]> >> >> <mailto:[email protected] >> <mailto:[email protected]>> >> >> View Raviteja >> Lokineni's profile on LinkedIn >> >> <http://in.linkedin.com/in/rav >> itejalokineni >> <http://in.linkedin.com/in/rav >> itejalokineni>> >> >> >> >> >> >> >> >> >> >> >> >> >>
