May I suggest using JRuby with Nailgun when running Buildr. Nailgun keeps a JVM running and thus using it with Buildr results in nearly no startup time. Nailgun is bundled with Jruby these days.
Regs, Tal On Mon, Aug 3, 2009 at 9:00 AM, Daniel Spiewak<[email protected]> wrote: > If switching between JDK versions is an essential feature, then really your > only option at present is to use JRuby. It's actually a pretty good way to > use Buildr, just as good in every respect except for startup time (~2 > seconds as opposed to ~50ms). If you're using a modern Sun VM (>=1.6.0_10) > then the startup time could be even less than 1 sec (at least in my tests). > > Hopefully, either I or someone else will get a chance to implement a > socket-based Ruby-Java bridge, but until then... :-S > > Daniel > > On Sun, Aug 2, 2009 at 8:12 AM, Martin Grotzke <[email protected] >> wrote: > >> On Sat, 2009-08-01 at 23:14 -0500, Daniel Spiewak wrote: >> > Minor versions should be ok, though I would be careful going between >> 1.6.0 >> > and 1.6.0_10 (or _03 and _14 as in your example). I'm honestly not sure >> > that switching between JDKs is a particularly common use-case. It's >> really >> > annoying that RJB is like this, but I don't see any other way as long as >> the >> > bridge is using JNI under the surface. >> In our company this is a common use case, as lots of developers are >> working on several projects that use different jvm versions - depending >> on the client, app server, project infrastructure etc. >> >> > >> > Another (possibly better) option would be to run Java in a sub-process >> > spawned by Ruby with socket communication between the two. This would >> > prevent incompatibility mismatch and cut the tight coupling to JVM >> > installations. The main downside to this is that no one has done >> anything >> > like this (to my knowledge), so it's not a pre-existing (stable) solution >> > like RJB. The immediate advantage to such a solution though is that it >> > would allow us to finally support Buildr on MRI with Java 6 on Mac. >> Puh, sound rather robust but also as if this would require huge amounts >> of work. >> >> Now I also addressed this in the rjb forum: >> http://rubyforge.org/forum/forum.php?thread_id=45030&forum_id=8190 >> >> Cheers, >> Martin >> >> >> > >> > Daniel >> > >> > On Sat, Aug 1, 2009 at 6:35 PM, Martin Grotzke < >> [email protected] >> > > wrote: >> > >> > > D'oh, no good news. What about switching between minor versions, e.g. >> > > from 1.6.0_03 to 1.6.0_14? >> > > >> > > Wouldn't it be good to be able to have several rjb versions running in >> > > parallel, and to switch them with s.th. like alternatives? (the rjb >> > > version then would have to include the used/linked jdk version, s.th. >> > > like <rjbversion-jdkversion>). >> > > >> > > Cheers, >> > > Martin >> > > >> > > >> > > On Sat, 2009-08-01 at 16:37 -0500, Daniel Spiewak wrote: >> > > > Yes, it does. >> > > > >> > > > Daniel >> > > > >> > > > On Sat, Aug 1, 2009 at 4:20 PM, Martin Grotzke < >> > > [email protected] >> > > > > wrote: >> > > > >> > > > > Does this mean, that when one switches the current jvm (e.g. from >> 1.5 >> > > to >> > > > > 1.6) one would have to reinstall rjb, so that it uses the correct >> jdk >> > > > > header files? >> > > > > >> > > > > Cheers, >> > > > > Martin >> > > > > >> > > > > >> > > > > On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote: >> > > > > > If it makes you feel any better, the problem is with RJB and not >> > > Buildr >> > > > > > itself. However, that doesn't change anything about user >> > > perception... >> > > > > > >> > > > > > To be honest, I'm with you on this one. I would much rather run >> > > Buildr >> > > > > > under MRI, or really *any* Ruby implementation other than JRuby. >> > > Don't >> > > > > get >> > > > > > me wrong, I love the JRuby project, but a tool like Buildr lives >> and >> > > dies >> > > > > by >> > > > > > startup time, an area where JRuby does very poorly. One option >> which >> > > > > might >> > > > > > work on Mac OS X (one which I haven't tried) is to use SoyLatte >> 32bit >> > > ( >> > > > > > >> > > > > >> > > >> http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2 >> > > > > ). >> > > > > > Note that if you take this route, you will need to do more than >> just >> > > set >> > > > > > JAVA_HOME and the PATH, you will need to actually symlink >> > > > > > >> > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries >> > > > > to >> > > > > > the correct directory within SoyLatte, and then >> > > > > > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK >> to >> > > > > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte. >> Crazy >> > > > > Apple >> > > > > > VM layout... >> > > > > > >> > > > > > As for running Buildr with Java 6 on other platforms, like Linux >> or >> > > > > Windows, >> > > > > > I've actually had a lot more success along those lines. To be >> > > honest, >> > > > > I've >> > > > > > never had it segfault on Windows, and on Linux only when RJB has >> been >> > > > > > incorrectly compiled/linked. So, the main trouble is Mac, and as >> the >> > > > > > "Common Problems and Solutions" document states, the trouble is >> 32bit >> > > MRI >> > > > > > mixing with 64bit Java. The only possible solution I can see >> here is >> > > to >> > > > > > create an entirely new Ruby-Java bridge based on sockets. >> Obviously, >> > > > > this >> > > > > > isn't a viable option (unless someone wants to volunteer?). >> > > > > > >> > > > > > So, that brings us back to square one. I don't know what else to >> say >> > > at >> > > > > > this point, we really have tried a lot of different solutions to >> this >> > > > > > problem, none of which have worked terribly well. >> > > > > > >> > > > > > Daniel >> > > > > > >> > > > > > On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke < >> > > > > > [email protected]> wrote: >> > > > > > >> > > > > > > Hi, >> > > > > > > >> > > > > > > I just want to address the issue, that with java 6 there can >> occur >> > > > > > > segfaults from time to time. The advice ([1]) is to go back to >> java >> > > 5 >> > > > > or >> > > > > > > to use jruby. Both solution are not ideal IMHO. java 5 might >> not be >> > > an >> > > > > > > option as there are already projects that require java 6, and >> jruby >> > > is >> > > > > > > not ideal as it has longer startup times of buildr. Therefore, >> from >> > > my >> > > > > > > point of view, running buildr "natively" is the best option and >> if >> > > it's >> > > > > > > required with java 6. >> > > > > > > >> > > > > > > For new users this might be an issue that causes a loss of >> trust in >> > > > > > > buildr and the stable build. >> > > > > > > >> > > > > > > Do you also think that this issue should be addressed and >> > > eliminated? >> > > > > > > >> > > > > > > Are you aware of any reasons that might cause the segmentation >> > > faults? >> > > > > > > >> > > > > > > I have also a concrete example (from one of my colleagues) with >> a >> > > > > > > segmentation fault. That's a part from the build output: >> > > > > > > >> > > > > > > $ buildr clean; buildr -t >> > > > > > > ... >> > > > > > > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26 >> > > +0200 >> > > > > 2009 >> > > > > > > (/home/philip/projects/final-folder/buildfile). Last successful >> > > test >> > > > > run: >> > > > > > > <EARLY TIME>. >> > > > > > > ** Invoke ff:core:test (first_time) >> > > > > > > ** Invoke /home/philip/projects/final-folder/buildfile >> (not_needed) >> > > > > > > ** Invoke ff:core:test:compile (first_time) >> > > > > > > ** Invoke ff:core:compile (not_needed) >> > > > > > > ** Invoke ff:core:test:resources (first_time) >> > > > > > > ** Execute ff:core:test:resources >> > > > > > > ** Invoke >> > > /home/philip/projects/final-folder/core/target/test/resources >> > > > > > > (first_time) >> > > > > > > ** Execute >> > > > > /home/philip/projects/final-folder/core/target/test/resources >> > > > > > > Segmentation fault >> > > > > > > >> > > > > > > This is caused by the invocation of just buildr (without any >> task), >> > > if >> > > > > > > buildr is invoked with a task (e.g. build, compile or test) >> there's >> > > no >> > > > > > > segementation fault. >> > > > > > > >> > > > > > > This are the versions of buildr, ruby and java: >> > > > > > > Java: 1.6.0_14 >> > > > > > > Ruby: 1.8.7 >> > > > > > > Buildr: 1.3.4 >> > > > > > > >> > > > > > > If that's also the case for other users, a first workaround >> might >> > > be >> > > > > not >> > > > > > > to promote the invocation of just "buildr", but instead say >> that >> > > > > "buildr >> > > > > > > build" should be run. >> > > > > > > >> > > > > > > What do you think? >> > > > > > > >> > > > > > > Thanx && cheers, >> > > > > > > Martin >> > > > > > > >> > > > > > > >> > > > > > > [1] >> > > > > > > >> > > > > >> > > >> http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > >> > > >> >
