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> >>> >>> >>> >>> >>> >>> >
