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