Forum: JRuby Why so complicated?

Why is it almost routine, whenever anyone looks for advice on this
Forum, to be advised to use things like RVM and Bundler (apparently
there is now even a JBundler).

These things may be useful for MRI Ruby (RVM certainly is) but JRuby
doesn't need them.

As far as I can see the simplest way to use JRuby is to download the zip
file with your preferred version and extract it into the directory where
you will build your project. Then create a short shell script or batch
file that will (a) add the JRuby /bin directory to the PATH and (b) open
a terminal at the project directory.

From that point on if you add gems (the usual way with gem install XXX)
they will be stored within the project. You can create a sub-directory
for jars to keep things tidy (perhaps /lib) and include them with
"require '/lib/xxx.jar'"

Everything is within the project directory and nothing can be mixed up
with any other project.

And if you want to run a copy of your project on another PC all you have
to do is copy the project directory and all its contents. The only thing
needed on the other PC is the JVM.

I can't understand why people spend dozens or hundreds of hours creating
something like Bundler (or JBundler) when a half dozen hours writing an
explanation of what needs to be done and how to do it would be a lot
"cheaper" in programmer-hours and more useful because then the users
would actually learn something rather than blindly following "black box"
instructions.

Hello,

> From that point on if you add gems (the usual way with gem install XXX)
> they will be stored within the project. You can create a sub-directory
> for jars to keep things tidy (perhaps /lib) and include them with
> "require '/lib/xxx.jar'"

It really depends on your personal needs.

If you need to have some copy-pastable deployment, then either using
bundler's cache or your system (called "vendoring" sometimes) makes 
sense.

I have some oldish JRuby 1.4 deployments where I do vendor gems manually
and it works perfectly well.

Now if this is some software that you plan to update/maintain regularly,
Bundler helps to make sure you'll just have to update the number, which
saves time (and I do that mostly now).

hope this helps,

Thibaut

the project I am working the last weeks s a typical classpath like this

nexus-ruby-tools-1.0.0-SNAPSHOT.jar
jruby-complete-1.7.0.preview2.jar
nexus-testsuite-support-2.2-SNAPSHOT.jar
nexus-launcher-2.2-SNAPSHOT.jar
sisu-bundle-launcher-1.3.jar
sisu-inject-bean-2.3.0.jar
sisu-guice-3.1.0-no_aop.jar
sisu-guava-0.9.9.jar
sisu-file-tasks-1.3.jar
ant-1.8.2.jar
ant-launcher-1.8.2.jar
statemap-6.0.1-java.jar
sisu-maven-bridge-2.3.jar
maven-model-builder-3.0.4.jar
plexus-component-annotations-1.5.5.jar
maven-settings-builder-3.0.4.jar
maven-settings-3.0.4.jar
plexus-sec-dispatcher-1.3.jar
plexus-cipher-1.4.jar
maven-aether-provider-3.0.4.jar
maven-repository-metadata-3.0.4.jar
aether-spi-1.13.1.jar
aether-impl-1.13.1.jar
aether-connector-wagon-1.13.1.jar
wagon-provider-api-1.0-beta-6.jar
wagon-http-2.1.jar
wagon-http-shared4-2.1.jar
jsoup-1.6.1.jar
nexus-bootstrap-2.2-SNAPSHOT.jar
appcontext-3.2.jar
plexus-interpolation-1.14.jar
sisu-jetty8-1.3.jar
jetty-server-8.1.3.v20120416.jar
javax.servlet-3.0.0.v201112011016.jar
jetty-continuation-8.1.3.v20120416.jar
jetty-http-8.1.3.v20120416.jar
jetty-io-8.1.3.v20120416.jar
jetty-util-8.1.3.v20120416.jar
commons-httpclient-3.1.SONATYPE.jar
commons-codec-1.2.jar
nexus-client-core-2.2-SNAPSHOT.jar
nexus-rest-api-model-2.2-SNAPSHOT.jar
maven-model-3.0.4.jar
security-rest-model-2.8.2.jar
slf4j-api-1.6.4.jar
plexus-utils-3.0.jar
xstream-1.4.2.jar
xmlpull-1.1.3.1.jar
xpp3_min-1.1.4c.jar
aether-api-1.13.1.jar
aether-util-1.13.1.jar
commons-lang-2.3.jar
commons-beanutils-core-1.7.0.jar
commons-collections-2.0.jar
jersey-client-1.12.jar
jersey-core-1.12.jar
jersey-apache-client4-1.12.jar
httpclient-4.1.1.jar
httpcore-4.1.jar
jcl-over-slf4j-1.6.4.jar
nexus-testsuite-client-2.2-SNAPSHOT.jar
goodies-marshal-1.4.jar
goodies-common-1.4.jar
sisu-guice-3.1.1.jar
javax.inject-1.jar
aopalliance-1.0.jar
jackson-core-asl-1.9.4.jar
jackson-mapper-asl-1.9.4.jar
litmus-testsupport-1.4.jar
logback-classic-1.0.1.jar
logback-core-1.0.1.jar
gossip-support-1.8.jar
gossip-bootstrap-1.8.jar
guava-10.0.1.jar
jsr305-1.3.9.jar
annotations-9.0.4.jar
junit-dep-4.10.jar
hamcrest-core-1.3.jar
hamcrest-library-1.3.jar
java-diff-1.1.jar
mockito-core-1.9.0.jar
objenesis-1.0.jar
powermock-module-junit4-1.4.12.jar
powermock-module-junit4-common-1.4.12.jar
powermock-reflect-1.4.12.jar
powermock-api-mockito-1.4.12.jar
powermock-api-support-1.4.12.jar
powermock-module-junit4-rule-1.4.12.jar
powermock-classloading-base-1.4.12.jar
powermock-core-1.4.12.jar
javassist-3.16.1-GA.jar
powermock-classloading-xstream-1.4.12.jar
junit-ext-1.0-RC3-junit45.jar
commons-io-1.4.jar
surefire-junit4-2.10.jar
surefire-api-2.10.jar

which gets declared by 2 or 3 jar dependencies. not sure if I would
like to "calculate" that classpath manually any time.

so I would say it depends . . .

- Kristian

In our projects we do exactly what your say, and even more:  We check 
the java and JRuby directories into version control, including the 
installed gems.  That way you only need to check out the project, and 
you are good to go.

It ensures all developers have the same version of everything, and that 
production is identical to development and test.

We sometimes wonder if we should change our practice, but regularly 
decide to keep the current setup.


On 2012-09-11, at 11:17, Robin McKay <lists@ruby-forum.com> wrote:

> file that will (a) add the JRuby /bin directory to the PATH and (b) open
> And if you want to run a copy of your project on another PC all you have
> --
> Posted via http://www.ruby-forum.com/.
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

--
Uwe Kubosch
uwe@kubosch.no
http://kubosch.no/

To me, the ideal way to handle this is the way it's done by Gradle.
 Instead of checking in the entire runtime environment, you simple check 
in
scripts that are smart enough to download and install the runtime you 
need.
 Seems like the best of both worlds, you get the safety of everyone 
using
the *exact* version of the software you want, but you don't have to 
check
in entire runtimes in to SCM.

We use this on several projects and I love it.  Wouldn't ever want to do 
it
differently now.

http://gradle.org/docs/current/userguide/gradle_wrapper.html

Joe

Interesting replies. It must be fun managing a project with so many JARs
as Kristian has. But I suspect that is not a typical situation, and
certainly not for a newcomer to JRuby.

People obviously have systems that work for themselves but it would
surely be very useful to have guidelines on the JRuby website for a
simple and transparent system that makes the best use of JRuby's
strengths - at least for newcomers or new projects.

It seems to me JRuby can greatly simplify Ruby program development and
that opportunity is being ignored by a slavish adherence to MRI Ruby
practices.