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.
on 2012-09-11 11:17
on 2012-09-11 11:29
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
on 2012-09-11 11:43
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-188.8.131.52.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
on 2012-09-12 21:26
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 <firstname.lastname@example.org> 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 email@example.com http://kubosch.no/
on 2012-09-13 16:15
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
on 2012-09-23 13:02
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.