So from reading the documentation, the way I'm attempting to invoke rspec is:
java -jar jruby-complete-1.6.7.jar -S spec -b -f d rspec_sanity_check.rb
I've also tried rspec instead of spec. In each case, I get the error:
jruby: No such file or directory -- spec (LoadError)
I'm not sure what to do here. Although the documentation says jruby-complete has rspec, I can't seem to run it.
I'm attempting to use jruby-complete to bootstrap our java based buildsystem so I don't have to install gems on each new vm.
Any thoughts on how to get jruby-complete rspec to work?
seems to work just fine with 1.6.7 :
$ java -jar org.jruby/jruby-complete.jar -S rspec
Run filtered using {:full_description=>/(?-mix:Handler)/}
No examples were matched. Perhaps {:if=>#<Proc:0x8d00c6#/opt/local/rvm/gems/ree-1.8.7-2011.12/gems/rspec-core-2.5.1/lib/rspec/core/configuration.rb:50>, :unless=>#<Proc:0x12dcb8c#/opt/local/rvm/gems/ree-1.8.7-2011.12/gems/rspec-core-2.5.1/lib/rspec/core/configuration.rb:51>} is excluding everything?
Finished in 0.002 seconds
0 examples, 0 failures
Related
In order to see the content of my parquet file, I tried running some parquet-tools commands using version 1.9.1 and version
1.6.1 and was quite surprised to see that the newer parquet-tools doesn't
work for me at all:
I want to run the parquet-tool using java -jar command. Bellow the commands I tried and the result obtained
java -jar parquet-tools-1.9.1-SNAPSHOT.jar meta /tmp/test.parquet
java -jar parquet-tools-1.9.1-SNAPSHOT.jar cat /tmp/test.paruet
The obtained result for both commands:
org/apache/hadoop/conf/Configuration
org/apache/hadoop/fs/Path
Can someOne guides me with sample example to resolve this.
Thansk in advance
I am trying to using Doop framework. I am following this link: https://bitbucket.org/yanniss/doop
I downloaded the code and compiled it successfully. but when I am trying to Running Doop by the following command
$ DOOP_HOME>./bin/doop -a context-insensitive -j ./lib/asm-debug-all-4.1.jar
in my case, it is :
./doop -a context-insensitive -j ../lib/asm-debug-all-5.0.3.jar
But, unfortunately, I got an error.
vuquangvinh#vuquangvinh-VPCEA24FM:~/tutorial/DoopFramework/code/doop/bin$ ./doop -a context-insensitive -j ../lib/asm-debug-all-5.0.3.jar
:: loading settings :: url = jar:file:/home/vuquangvinh/tutorial/DoopFramework/code/doop/lib/ivy-2.3.0.jar!/org/apache/ivy/core/settings/ivysettings.xml
The EXTERNALS directory is invalid: null
I have no idea what is happening. I have tried, but this framework seems to be not popular. Anyone can help me!
Many thanks!
As stated in the documentation the tool expects several environment variables DOOP_HOME, DOOP_OUT, DOOP_HOME and DOOP_EXTERNALS to be set and it simply complains that DOOP_EXTERNALS is not set.
Instead of setting the environment variable you can also pass the externals directory via command line option --externals <the directory>.
I just want to be able to do ./whatever.jar instead of java -jar whatever.jar.
I've found a way:
#!/bin/bash
java -jar $0 $*
exit
# jar goes here...
but it doesn't work. Java just complains that it's an invalid/corrupt jarfile.
I also tried piping:
#!/bin/bash
tail -n +4 $0 | java -jar
exit
# jar goes here...
but this doesn't work.
One way to do it is to somehow split the file into two separate parts (the script part and the jar part), and then execute the jar, but that'd be redundant. You'd might as well make a script that executes the jar and execute that script.
So I need to figure out how to somehow tail it and fake the file.
I thought I could do it using /dev/stdout:
#!/bin/bash
java -jar /dev/stdout
tail -n +5 $0
exit
# jar goes here...
That doesn't work either. It just prints the contents of the jar and java complains that it's invalid. (I figured out later that there's nothing to read in /dev/stdout)
So I need to read from stdout some other way. I really wish I could pipe it though. It would make things SO much easier :)
You need a service called jexec some linux distros come with this installed check for /etc/init.d/jexec. My CentOS 5.5 definitely does.
What it does is register the jexec interpreter with the binfmt system.
For more information you might what to have a quick read of binfmt_misc.
Assuming you have the kernel source code installed, check out /usr/src/linux/Documentation/java.txt for a way to run Java code directly using the kernel's BINFMT_MISC support (assuming it's compiled into the version of the kernel you're running, but I think it is on most major distros). If you don't have the source installed, you should be able to find it online easy enough (here's one example).
FYI, if you wanted to do it your original way it would go like this:
$ cat jar.sh
#!/usr/bin/env bash
java -jar <(tail -n +4 "$0")
exit
$ cat jar.sh runme.jar > works.jar
$ chmod a+x works.jar
$ ./works.jar
Presuming a recent bash with support for <()
java -jar does not work with stdin, apparently it does some seeks rather than straight reads.
On a system you can't mod, you have to use a tmp. for example.
#!/bin/bash
JF=/tmp/junk$$.jar
(uudecode -o /dev/stdout >$JF;java -jar $JF;unlink $JF) <<JAR
begin-base64 644 junk.jar
UEsDBBQACAAIAEaBz0AAAAAAAAAAAAAAAAAJAAQATUVUQS1JTkYv/soAAAMA
UEsHCAAAAAACAAAAAAAAAFBLAwQUAAgACABGgc9AAAAAAAAAAAAAAAAAFAAA
AE1FVEEtSU5GL01BTklGRVNULk1G803My0xLLS7RDUstKs7Mz7NSMNQz4OVy
LkpNLElN0XWqBAmY6RnEG5koaASX5in4ZiYX5RdXFpek5hYreOYl62nycvkm
ZubpOuckFhdbKWSV5mXzcvFyAQBQSwcIBHn3CVkAAABZAAAAUEsDBBQACAAI
AEd+z0AAAAAAAAAAAAAAAAAKAAAAanVuay5jbGFzc21QTUvDQBB926RJE6Ot
ramfhXoQogcDXiteBPFQVIjowdOmXcrGZCMxEfxZelDw4A/wR4mzUShCF3Zn
9s2bt2/26/vjE8ARBi4stB10sNpC10UPazZ8G30G61gqWZ4wGMH+DYN5mk8F
Q3sslbioslgU1zxOCTEzLhVDP7gbJ/yJhylXszAqC6lmI93oRnlVTMSZ1GQn
qdT9oeZ5sNGyse5hA5sM3rlI03x4mxfpdNfGlodt7JC45jN05sqXcSIm5T8o
en4sRUZG84oK/q8NmYdX5KEkJ4JnI4beApjBftC3lAbwg0X+MUSTvkivBm3y
DJqCsgFFRrF58A72QglNSqdVg5qyBO+PuketGnVe0egabzDndLdWNUjVJGS5
fmXlB1BLBwjDUWL/IAEAAJ4BAABQSwECFAAUAAgACABGgc9AAAAAAAIAAAAA
AAAACQAEAAAAAAAAAAAAAAAAAAAATUVUQS1JTkYv/soAAFBLAQIUABQACAAI
AEaBz0AEefcJWQAAAFkAAAAUAAAAAAAAAAAAAAAAAD0AAABNRVRBLUlORi9N
QU5JRkVTVC5NRlBLAQIUABQACAAIAEd+z0DDUWL/IAEAAJ4BAAAKAAAAAAAA
AAAAAAAAANgAAABqdW5rLmNsYXNzUEsFBgAAAAADAAMAtQAAADACAAAAAA==
====
JAR
Or I could just install the jarwrapper (Ubuntu) package.
Write a separate shell script:
whatever.sh
#!/bin/bash
java -jar whatever.jar $*
You can't make the JAR file directly executable because it's not an executable file. It's Java bytecode which can't be read directly by the machine nor any standard shell interpreter that I know of.
I made some little programs with Swing-components in JRuby. Now I want to convert these to .jar-archives.
The first option I found is warbler: https://github.com/jruby/warbler
Making a jar should be as simple as:
$ chmod a+x bin/mylittleprogram.rb
$ warble jar
But warble is aborted with an error: "can't modify frozen string"
same issue as here: https://github.com/jruby/warbler/issues/76
I'm a newbie and, frankly speaking, I don't get from the thread at github what to do (like: look for x in file y and change it to z) to make it work. Like the guy who started the thread, I have an Ubuntu OS (11.04) und MRI and JRuby installed.
I also found rawr: http://rawr.rubyforge.org/
Making a jar should work as follows:
rawr install
rake rawr:jar
java -jar package/jar/your_jar_file.jar
In my case, I get an error:
Exception in thread "main" org.jruby.exceptions.RaiseException: (LoadError) no such file to load -- main
My Question: Which of these two options will be easier to use?
It would be also very helpful, to get an explanation what warbler and rawr do in the background.
Many thanks in advance!
Rawr is quite simpler for the standalone app. In your case, I guess you haven't specified the main class yet. You should check it on build_configuration.rb
# The main ruby file to invoke, minus the .rb extension
# default value: "main"
#
c.main_ruby_file = "hello"
where in my case, hello.rb is the main ruby file.
According to the Warbler bug you refer to, the fix has been merged, but it looks like no gem has been released since.
I suggest you try building a latest warbler gem from the github source, as per this question
Consider the following script:
println "ls -l".execute().text
Why do I get the following error when running with JDK 1.6.0_14?
Caught: java.io.IOException: Cannot run program "ls": java.io.IOException: error=40, Too many levels of symbolic links
at a.run(a.groovy:2)
When run with JDK 1.5.0_08 I get the expected output. This, by the way, is one of the examples on the Groovy Process management page. A simple solution seems to be to run it within a shell:
println ["/bin/sh", "-c", "ls -l"].execute.text
But this shouldn't be necessary, no?
Have you tried this?
println "/bin/ls -l".execute().text