On Tue, Aug 17, 2010 at 11:55 PM, Antoine Toulme <anto...@lunar-ocean.com> wrote: > OK, I'm in touch with the debian team, and I'll see what it takes to sneak > buildr as part of the gentoo distribution, before I push this further. > If you are involved with gentoo, no
did I write ruby ebuilds for gentoo before - yes, there are one or two or three I laid my hands on and I had a tool to convert gemspec to ebuild. so if I remember it right it was rather straight forward. but I dump gentoo a year ago - it was too time consuming for me. but after this email thread, let me see if I am able to setup a minimal gentoo virtual box. I looked at the deps of buildr and most of them have already ebuilds. missing bits are Antwrap, json_pure, jekyll, sdoc. hope you know that you asked a maven guy to help you with buildr ;-) yes, I see where to steal the time for that . . . regards Kristian > I'd be happy to discuss with you on the > best way to make buildr happen there. > Thanks, > Antoine > > On Tue, Aug 17, 2010 at 04:52, kristian <m.krist...@web.de> wrote: >> >> as a jruby user I need better artifact as there are now. >> >> as a jruby user I would like to install jruby from the OS and here I >> see only gentoo up to date. >> >> the moment there a gems or other application in need of jruby it must >> come through the OS. putting buildr on top of jruby will just increase >> the mountain to climb for distributions - BUT maybe I am wrong and >> buildr build is easier to understand and with this easier to adopt ;-) >> >> just needed to bring the attention to the OS I am working with which >> has no jruby-1.5.x yet. and any application using jruby has to wait >> until jruby is part of the OS. >> >> regards Kristian >> >> >> >> >> On Tue, Aug 17, 2010 at 4:40 PM, Alistair Bush <ali_b...@gentoo.org> >> wrote: >> >> Hi Kristian, >> >> >> >> actually some Fedora folks contacted me and I think there is a bundle >> >> for >> >> Buildr now since they use it for Candlespin. >> >> I don't know if there is a bundle for Debian but I'd be glad to make it >> >> happen. >> >> >> >> Our installation instructions are probably outdated - we can work on >> >> that, >> >> and having a Debian package would certainly help. >> >> >> >> Yes, we can provide a javadoc bundle and a source bundle, and we can >> >> push >> >> them next to the jar on the Maven repo. We don't generate the checksums >> >> yet, but I would certainly add this in a near future. >> >> >> >> As to your final question on how to build jruby without jruby, my >> >> answer >> >> earlier was probably unclear. >> >> You download this file ( >> >> >> >> http://rubyforge.org/frs/download.php/71279/buildr-all-in-one-1.4.0.tar.gz) >> >> , unpack it, and use the buildr package script there. >> >> You can also install Buildr with MRI, but that's more work. >> >> >> > >> > Lets get this straight, bundling jruby with buildr still means you are >> > using >> > jruby. From a package manager perspective the first thing I would need >> > to do >> > is replace jruby with a system version. If that isn't possible because >> > jruby >> > is built with buildr then buildr would need to work with MRI otherwise >> > jruby >> > and builr would be impossible to package. Just because you provide >> > jruby >> > doesn't break the circular dependency. >> > >> >> Thanks, >> >> >> >> Antoine >> >> >> >> On Mon, Aug 16, 2010 at 19:24, kristian <m.krist...@web.de> wrote: >> >> > hello, >> >> > >> >> > I have a few thoughts about jruby and why is there no jruby in fedora >> >> > or outdated version in ubuntu/debian - gentoo is quite impressive >> >> > (and >> >> > better then it was when I used gentoo myself). >> >> > >> >> > all these linux distributions are about dependency management. and >> >> > when building a package there needs to be all dependent "libraries" >> >> > already available and installed. it seems rather difficult to adopt >> >> > the ant script in a way that ant builds from the packages of the >> >> > distribution rather then the jars files from the code repository. >> >> > dito >> >> > is probably true for maven. but most big linux distributions can >> >> > provide ant and maven more or less up-to-date. >> >> > >> >> > next issue I see with buildr. none of the distributions I know have >> >> > any buildr package. >> >> > >> >> > and the big thing is the dependency management. and "assume" buildr >> >> > is >> >> > a better maven it does a lot of dependency management and here things >> >> > become tricky for the distributions. like debian and rubygems >> >> > (another >> >> > dependency management something) - debian disallows to "sudo gem >> >> > update --system" since this would break the system consistency. >> >> > >> >> > the moment jruby has a build system which is not ant or maven based >> >> > you will not see jruby in these linux distributions for a long time >> >> > (<- my prediction). >> >> > >> >> > if I look how buildr wants me to install buildr on linux >> >> > (http://buildr.apache.org/installing.html#linux) is basically fouling >> >> > apt or yum the packagemanagers by first replacing rubygems with a >> >> > version which is not "known" by apt or yum and then "sudo gem install >> >> > .... " which might pull in even more gems which will not match what >> >> > the package management knows. (better change the docs to a "gem >> >> > install --user-install ..." and start to behave nice with the >> >> > underlying OS.) >> >> > >> >> > anyways my wish-list for any build system would be: source + javadocs >> >> > artifact attached to the jruby/jruby-complete artifact so maven based >> >> > IDEs can use these to provide access to source + javadocs. and >> >> > correct >> >> > checksums (which is not the case right now for some org.jruby.extra.* >> >> > jars). >> >> > >> >> > >> >> > On Mon, Aug 16, 2010 at 8:29 PM, Antoine Toulme >> >> > <anto...@lunar-ocean.com> >> >> > >> >> > wrote: >> >> > > 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 >> >> > >> >> > ? >> >> > >> >> > first you need a buildr ebuild so you can use it as tool for building >> >> > other packages. then dissect the buildfile so the actual build uses >> >> > the packages from Gentoo and NOT the ones from the maven repository >> >> > or >> >> > from the git repository. and so on and on and on. >> >> > >> >> > > 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. >> >> > >> >> > question: how do build jruby without jruby. which is needed if you >> >> > build an OS from source from scratch. >> >> > >> >> > regards Kristian >> >> > >> >> > >> >> > 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 >> >> > >> >> > --------------------------------------------------------------------- >> >> > >> >> > 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 >> > >> > >> > >> >> --------------------------------------------------------------------- >> 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
