buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tammo van Lessen <>
Subject Buildr "Wrapper"
Date Fri, 13 Mar 2015 08:05:39 GMT
Hi devs,

Occasionally I get complaints that ODE should really use Maven as this is
the real standard and everything else is proprietary non-sense. I then tell
them why Buildr was created and why the ODE build is so complex that doing
the same in Maven is either impossible or cumbersome in the best case. But
I also ask about the problems they experience with Buildr, since for me in
most cases it just works. The main complaint is that Buildr is difficult to
get installed and started with.

What I'd like to discuss is whether or how we could improve this situation.
I think the Gradle team found a neat way to approach this topic with their
"gradle wrapper". This is a combination of sh/batch files along with a tiny
jar that is capable to download gradle into the working copy. This allows
to bootstrap the build with only Java as a prerequisite and is added to
version control.

I think having something similar would significantly improve the
"occasional user experience".

Would you agree up to this point?

If so, I wonder what would be the easiest and Buildr/Ruby-ish way to get to
such a solution, since Buildr is somewhat different to Gradle regarding its
dependencies. For instance I usually use a Gemfile to define the required
Buildr version and additional dependencies.

I think a usable approach could be to have a similar wrapper jar that just
downloads a stable jruby (version configurable) from Maven Central,
deflates its to a .buildr/jruby directory within the working copy and then
run jruby in jailed fashion (to make sure that Buildr and deps are
installed into this directory in the working copy), invoking bundler and
finally buildr.

Do you think thats feasible and worth the effort? Are there additional
corner cases to address? Do you have some experience in mixing Java and
Ruby code for such a launcher?


Tammo van Lessen -

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message