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. 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 > > >
