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