Hi Peter, The easiest way would be:
jruby --ng -S buildr (after starting the ng server using jruby --ng-server) I'll put it in the wiki. Regards, Tal Rotbart On Mon, Aug 3, 2009 at 10:34 PM, peter schröder<[email protected]> wrote: > Hi Tal, > > how exactly do you start buildr using jruby --ng ? > > could you put this stuff in the buildr wiki? > > i saw some commit-messages with nailgun in the buildr addon-trunk what about > dat? > > kind regards, > peter > > Am 03.08.2009 um 12:27 schrieb Tal Rotbart: > >> 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 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > > _________________________________ > Peter Schröder > IT > > blau: +49 (0) 178 139 1035 > fax: +49 (0) 40 288 071 - 71 > mail: [email protected] > > blau Mobilfunk GmbH > Schulterblatt 124 > D-20357 Hamburg > > Sitz: Hamburg > HRB 80531 Amtsgericht Hamburg > Geschäftsführer: Dirk Freise, Martin Ostermayer, Thorsten Rehling > >
