So I pick up 3 concerns: 1. It has to do at least a better job than the previous build, and be easy to adopt. 2. It has to build from source. 3. It depends on jruby.
1. in my opinion is a no-brainer. If there is no advantage and it's hard to play with, why bother. 2. is tricky, because it sounds deceptively easy. After all, if you want to build with buildr, you can checkout the tag and do buildr package, and you'll be done with it. I'm not sure what gentoo needs additionally to make it happen. Alistair, can you explain some more the pitfalls there please ? 3. In my opinion, there is no circular dependency. Either install buildr with MRI, or use our standalone integration with jruby over its last release. Buildr is then available in the same way ant is, and you won't see that it's powered by jruby. As long as you can build with a given combination of jruby+buildr, you won't need to depend on either HEAD. Eventually, adding your buildr build to your integration tests would probably help (Buildr was broken with jruby 1.5 over the implementation of Array#detect if I remember well). Buildr is very stable, we're packing changes and building an integration test suite, but most of the action is going on in extensions these days (at least that's where my free time goes, sadly). Overall that sounds like normal concerns, and I don't see a blocker. My plan is to contribute a buildfile, and you guys can gradually switch to Buildr if you feel at ease with it. It's a good learning process for Buildr as well. Thanks, Antoine On Sun, Aug 15, 2010 at 07:25, Wayne Meissner <wmeiss...@gmail.com> wrote: > Those are my concerns too. For those things like jffi and jruby > itself where using buildr would create a circular dependency, having > buildr as an alternative is fine, just not the main build system. > > If it could exterminate the maven vermin, it would be well worth it. > > On 13 August 2010 09:12, Charles Oliver Nutter <head...@headius.com> > wrote: > > Here's my concerns: > > > > * We've already started moving our build into Rake a bit by bit, and > > the bootstrapping question becomes apparent very quickly. In other > > words, we need JRuby (or Ruby) to run Buildr/Rake, but need > > Buildr/Rake to build JRuby. > > * Our Ant build has been a bitch to maintain, but now that it works > > pretty much everyone can build out of the box. That's very valuable. > > > > I would guess that Buildr would make our Maven nonsense easier, and > > maybe even allow us to yank out of our src the libraries that can be > > directly fetched from Maven (like we have experimented with using Ivy > > in the past), so that's definitely a bonus. And of course not having > > to maintain the Ant script is a benefit in any case. > > > > I am interested in hearing other opinions. > > > > - Charlie > > > > On Thu, Aug 12, 2010 at 5:08 PM, Antoine Toulme > > <antoine.tou...@gmail.com> wrote: > >> Hi devs, > >> I would like to contribute a Buildr based build to JRuby. Buildr is a > >> Rake-based build system that integrates well with Maven repositories, > has a > >> goal-based lifecycle that is very easy to extend and work with. > >> Buildr works on top of MRI or JRuby. > >> I recently contributed a build using Buildr for jffi that shows a > drastic > >> reduction of the complexity of the ant build files. > >> It is currently waiting for review on jira, and there may be more work > as my > >> C skills didn't allow me to finish the C compilation part: > >> http://jira.codehaus.org/browse/JRUBY-4970 > >> This email is meant to test the waters. Please also note I would work on > the > >> build system on my own as time permits, so I cannot give a firm date to > >> contribute it. > >> Any strong objections ? > >> Thanks, > >> Antoine > > > > --------------------------------------------------------------------- > > To unsubscribe from this list, please visit: > > > > http://xircles.codehaus.org/manage_email > > > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
