groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Keegan Witt <keeganw...@gmail.com>
Subject Re: Looking for testers & feedback: new Groovy binaries for Windows
Date Mon, 26 Sep 2016 18:18:50 GMT
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 <keeganwitt@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 <blackdrag@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 <contacto@nazcasistemas.com
>>> <mailto:contacto@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 <keeganwitt@gmail.com
>>>     <mailto:keeganwitt@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
>>>         <keeganwitt@gmail.com <mailto:keeganwitt@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.lokineni@gmail.com
>>>             <mailto:raviteja.lokineni@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
>>>                 <contacto@nazcasistemas.com
>>>                 <mailto:contacto@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
>>>                     <keeganwitt@gmail.com <mailto:keeganwitt@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.lokineni@gmail.com
>>>                 <mailto:raviteja.lokineni@gmail.com>
>>>
>>>                 View Raviteja Lokineni's profile on LinkedIn
>>>                 <http://in.linkedin.com/in/ravitejalokineni>
>>>
>>>
>>>
>>>
>>>
>>>
>

Mime
View raw message