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