consider running the jar without unpacking it

[mkristian]

with https://github.com/mkristian/jruby-mains I created a few "Main" classes which do execute the jar as is without unpacking it. this requires jruby-1.7.19 since the CWD (or PWD) needs to be inside the jar for tools like rake to find the right Rakefile.

it really reduces the startup time by 2-3 sec on my machine not to extract the jar.

[rtyler]

The jar should already be run without unpacking, since we're not using the JarMain bootstrap code from warbler in the jar plugin. It is used in the war plugin however`

Have you published the jruby-mains code to maven central or jcenter in such a way that might make sense to incorporate it?

[rtyler]

@mkristian your original report references changes in 1.7.19 to Dir.pwd or something similar, do you have a commit reference I could look at? A fix to that might actually correct #23

[mkristian]

https://github.com/jruby/jruby/tree/jruby-1_7/maven/jruby/src/it/runnable
is the test-case and the src/main/java/Main.java in there was the base for the https://github.com/mkristian/jruby-mains module.

yes, the test will pick the Rakefile from within the jar but probably I should delete the Rakefile before executing the code and run the execution inside another directory.

let me see if find the commit on jruby code side as well.

[mkristian]

regarding jruby-mains, I will release it tomorrow or so to maven-central.

[mkristian]

jruby/jruby@ef39dd5
jruby/jruby@3d56328

are the changes to change the directory into the classloader space

[mkristian]

jruby-1.7.19 can chdir into a jar file now and I released de.saumya.mojo:jruby-mains:0.1.0 to maven central

[rtyler]

@mkristian I can update to 1.7.19 as the default, but could you clarify what's beneficial about the jruby-mains code over what we're using right now? I think @ysb33r might also be interested in the answer

[mkristian]

well, after I released the artifact I can exchange the test on jruby itself using this artifact, i.e. tested with every jruby version is a benefit. it can use run a ruby application from within jar or war file without unpacking it and will find the Rakefile and Gemfile inside the jar/war. execution from an un-extracted jar/war is faster especially for bigger applications. I used a rather big application (from lookout) for prototyping. rake and bundler were kind of difficult to get work consistently. well, the main idea was to reduce the amount of similar code which is around: warbler, jruby-gradle-plugins and my plugins for ruby-maven which I need to leverage to bundle war files which work on ALL servlet engines including web-archive-OSGi bundles (I am not really keen on diving into warbler especially since warbler is ruby app centric but not useful for java apps with ruby-scripting-containers). so I guess the main reason is the bigger the user-base the more bugs get fixed and the better it is for everyone and jruby-gradle-plugins is still in state of "becoming" ;)

[mkristian]

this is the default now