> 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, I'd be happy to discuss with you on the > best way to make buildr happen there.
No but I am. > > 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.g > > z ) > > > > >> , 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
