What would the advantage be for such a third port over simply Buildr on JRuby? Faster startup time maybe, but the startup time would be more than dwarfed by the overhead of constantly shelling out.
Daniel On Sun, Mar 21, 2010 at 10:47 PM, Antoine Toulme <[email protected]>wrote: > 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 > >> > > >> > > > > >
