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
