I don't want to drop Java integration. It's our differentiator. I want to add a third port that uses subshells to get the job done - same way it's done in Maven today (because apparently, Maven does use a subshell for compilation).
On Sun, Mar 21, 2010 at 16:57, Alex Boisvert <[email protected]>wrote: > Personally, I'm still enjoying using MRI more than JRuby. If it wasn't > for installation issues and getting JDK 1.6 working on some machines, I'd be > a completely happy camper. > > I think Daniel illustrated well that we need more than exec("java") > functionality to retain the speed and integration we currently have. And > if anything, I want Buildr to have better Java integration, not less, so I > would not want to go to a situation where we have to shell out to "java" > every time something needs to invoke bytecode. I'm happy with using RJB as > lowest common denominator for what should work on Buildr in a standard > sense, and possibly using JRuby for extra features. > > And while I'm a big supporter of having a fully supported, all-in-one JRuby > distro, I don't yet see what we would gain from going JRuby-only and > dropping support for MRI. I would be fine making the JRuby distro our > recommended choice on the download page, though, since it would probably > result in better first experience. > > alex > > > On Sun, Mar 21, 2010 at 12:34 PM, Daniel Spiewak <[email protected]>wrote: > >> I think we rely on being able to call onto the JVM too much to do this. >> It's not just for compiler invocation. The most creative use (in my >> opinion) is our test class detection, which works by spinning up a >> URLClassLoader and filtering specified .class files for specific >> attributes >> (such as name or superclass). Of course, as with everything JVM-related >> that we're doing, we could just shell out, but that means we would have to >> eat the cost of JVM startup not once, but several times over the course of >> a >> normal build. There are also tools like Cobertura or the *entire* Groovy >> integration layer which are fairly heavily dependent on Ant. It would be >> annoying and tricky to enable these things through mere shell invocation. >> >> I think the main problem we're trying to solve here is the fact that RJB >> is >> flaky, difficult to install and causes endless compatibility issues. I >> would much sooner solve this problem by going JRuby-only. I mean, I like >> MRI as much as the next guy (particularly for startup), but JRuby has made >> pretty significant strides here in the most recent release. We could do >> even better if we pre-compiled all of the relevant .rb files and >> encouraged >> the use of the all-in-one bundle (still supporting gem installations, but >> only on JRuby). >> >> Just to be clear, I'm not exactly a fan of this idea. MRI support offers >> some very nice advantages (like Growl integration, startup time, etc). >> However, if we are seriously looking to get away from RJB, then I think we >> should do it by going to JRuby, rather than ditching JVM integration >> altogether. >> >> Daniel >> >> On Sun, Mar 21, 2010 at 1:24 PM, Antoine Toulme <[email protected]> >> wrote: >> >> > Hi guys, >> > >> > I'd like to open a new discussion with Buildr and offer a new insight on >> > Buildr's link to Java. >> > >> > From day one, Buildr was tightly bound to Java. We use either RJB or >> JRuby >> > as the gateway to Java, and we have one common API to discuss with it. >> > We use the Java integration in critical yet well defined operations: >> > compiling is for sure one, we also run some tools directly. >> > >> > I think we could find a way to make Buildr less resilient on Java. I >> wrote >> > an experimental compiler that relies on an external javac recently here: >> > >> > >> http://github.com/intalio/buildr4osgi/blob/master/lib/buildr4osgi/compile/external.rb >> > >> > This compiler helps me as I need to use a different JDK for part of the >> > projects I have to compile. >> > >> > I think the Java integration of Buildr helps starting the JVM only once >> - I >> > also think we could support most scenarios by calling Java over a >> subshell. >> > I don't know how much more expensive it would turn out to be but I see >> it >> > as >> > a good option - when RJB breaks, or when JFFI refuses to load, which >> > happens >> > all too often. >> > We know the main problem of Buildr is its installation story. How about >> we >> > give a drop and run Buildr gem that just relies on the JVM by calling >> it, >> > instead of linking to it ? That would make for less headaches and work >> > allright on most OSes. >> > >> > I would like to make such an implementation - as time permits. >> > >> > Please let me know what you think. >> > >> > Thanks, >> > >> > Antoine >> > >> > >
