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 >
