Hey Keegan,
Looks like there is a problem with Grapes and the .exe files:
I am attaching the test code (a sqlite example from SO)
When i use the groovy.bat i got:
c:\Data\Samples\Groovy\sqlite>groovy.bat samplesqlite.groovy
id=1, name= leo
id=2, name= yui
When i use the groovy.exe i got this error:
c:\Data\Samples\Groovy\sqlite>groovy.exe samplesqlite.groovy
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup
failed:
General error during conversion: No suitable ClassLoader found for grab
java.lang.RuntimeException: No suitable ClassLoader found for grab
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at
org.codehaus.groovy.reflection.CachedConstructor.invoke(CachedConstructor.java:83)
at
org.codehaus.groovy.runtime.callsite.ConstructorSite$ConstructorSiteNoUnwrapNoCoerce.callConstructor(ConstructorSite.java:105)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallConstructor(CallSiteArray.java:60)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:235)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callConstructor(AbstractCallSite.java:247)
at groovy.grape.GrapeIvy.chooseClassLoader(GrapeIvy.groovy:184)
at groovy.grape.GrapeIvy$chooseClassLoader.callCurrent(Unknown Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166)
at groovy.grape.GrapeIvy.grab(GrapeIvy.groovy:251)
at groovy.grape.Grape.grab(Grape.java:167)
at
groovy.grape.GrabAnnotationTransformation.visit(GrabAnnotationTransformation.java:378)
at
org.codehaus.groovy.transform.ASTTransformationVisitor$3.call(ASTTransformationVisitor.java:321)
at
org.codehaus.groovy.control.CompilationUnit.applyToSourceUnits(CompilationUnit.java:931)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:593)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:569)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:546)
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:298)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:268)
at groovy.lang.GroovyShell.parseClass(GroovyShell.java:688)
at groovy.lang.GroovyShell.run(GroovyShell.java:517)
at groovy.lang.GroovyShell.run(GroovyShell.java:507)
at groovy.ui.GroovyMain.processOnce(GroovyMain.java:653)
at groovy.ui.GroovyMain.run(GroovyMain.java:384)
at groovy.ui.GroovyMain.process(GroovyMain.java:370)
at groovy.ui.GroovyMain.processArgs(GroovyMain.java:129)
at groovy.ui.GroovyMain.main(GroovyMain.java:109)
1 error
Thanks!
Paco.
On Tue, Oct 11, 2016 at 4:50 PM, Keegan Witt <[email protected]
<mailto:[email protected]>> wrote:
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" <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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
<[email protected] <mailto:[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]
<mailto:[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] <mailto:[email protected]>>
wrote:
I started experimenting with launch4j, and have
put that experiment in this
repo: https://github.com/keeganwitt/groovy-launch4j
<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]
<mailto:[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]
<mailto:[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]>
<mailto:[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]>
<mailto:[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]>
<mailto:[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]>
<mailto:[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]>
<mailto:[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]>
<mailto:[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>
<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/groovy-windows-installer
<https://github.com/groovy/groovy-windows-installer>>
orgroovy-native-launcher
<https://github.com/groovy/groovy-native-launcher
<https://github.com/groovy/groovy-native-launcher>>).
To make it
easy to test, you can download the
compiled
binaries from here
(https://drive.google.com/folderview?id=0B_uOQFeu84v0TDVkS00xeE5yNHc&usp=sharing
<https://drive.google.com/folderview?id=0B_uOQFeu84v0TDVkS00xeE5yNHc&usp=sharing>
<https://drive.google.com/folderview?id=0B_uOQFeu84v0TDVkS00xeE5yNHc&usp=sharing
<https://drive.google.com/folderview?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]>
<mailto:[email protected]
<mailto:[email protected]>>
View Raviteja
Lokineni's profile on LinkedIn
<http://in.linkedin.com/in/ravitejalokineni
<http://in.linkedin.com/in/ravitejalokineni>>
