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
