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 <https://sourceforge.net/p/launch4j/git/ci/master/tree/head_src/head.c>, and as mentioned here <https://sourceforge.net/p/launch4j/discussion/332684/thread/b41c22bc/>). I opened an issue <https://sourceforge.net/p/launch4j/bugs/162/> 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 <[email protected]> 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 <[email protected]> > 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 <[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> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> >
