Hi Alistair, thanks for posting! Comments below... On Thu, Mar 11, 2010 at 12:34 AM, Alistair Bush <ali_b...@gentoo.org> wrote: > May I suggest that the "sweet spot" for linux binaries is to have them > packaged by there respective distro. Linux users really should be using their > package manager for installing jruby. > > Within gentoo I know there is current a push by one dev to make jruby a > standalone, drop in replacement for ruby. The same would occur for jython if > it didn't lag so much.
I would agree 100%, if we knew how to ensure that the dists were all updated properly and kept current with JRuby releases. As it stands now, JRuby has been bumped to non-free on Debian because there's not enough resources to get its component libraries released (i.e. there's no equivalent dynamo like Diego for Ruby on Debian), and I believe RedHat has orphaned JRuby. We obviously don't have resources to maintain distributions for every Linux variant, so what can we do? > Java and ruby [1] projects seem to have this idea that because there > applications can "run everywhere" they shouldn't be able to be "built > everywhere". Many java projects are a really pain to package for gentoo. > > Some of the common mistakes are > * Bundling jars within jars ( or using jarjar to combine them all ). tomcat > for example combines *parts* of 3 common-* jars into 1. This itself is a lib > of the source build so isn't reproducible. I realise why you do it for jruby- > complete.jar, but it would be oh so very very nice if it was extremely easy > not to do it. It wouldn't be hard to fix this, but we're fighting a war on two fronts. On the one hand, people want a Ruby-like package that produces "an executable" and a minimal distribution they can use. For them, having 30 jar files that must be available whereever jruby.jar is used stinks of complexity and bloat. So we jarjar most librares into both jruby.jar and jruby-complete.jar, providing a "Ruby-in-a-JAR" for those folks. On the other hand, we have the Java world, where people have become comfortable (perhaps reluctantly) with applications using dozens of jar files, and expecting to share component libraries across top-level libraries and applications easily. But even here there's conflict: most Java developers really do just want "a jar" they can embed, but then they also want to manage dependencies separately. Using jarjar is a pragmatic choice, but we're more than happy to provide a build target or config that just produces a "plain" jruby.jar. It's a 30 second addition, really. > * Ignoring CC, CFLAGS and LDFLAGS [2]. (Very very very common) Hopefully > someone will get around to sending patches upstream for you guys. We'd happily incorporate such patches. http://bugs.jruby.org is the quickest way to get it into the system. FWIW, we're going into RC mode for JRuby 1.5, so if there's patches to be had hopefully they'll show up sooner rather than later. > * Not providing source releases of packages (jffi, jna* guys). Having to > fetch > from scm's can be very annoying. At least you guys tag your releases. Try > getting the source code for a package version when you need to know the last > time the dev making the release sync'd trunk. "Releases" in what way? Do you mean source tarballs? I think we can work that into the release process, which probably just includes binaries and maven right now (and possibly just maven). > * not using -source and -target with javac (we automagically rewrite build.xml > files to 'fix' this). I think we've fixed this in our jruby build, but the other libraries may not have it. Again, we're more than happy to repair them on our end if "you" can point them out. > * including unit tests within the the production jar I don't think we have this problem in JRuby proper, but perhaps some of the component libraries do. > In fact it might be nice if you read our ebuild [3] [4]. Hopefully you will > be able to follow it. I'll certainly put it into the queue, but since I don't use or run Gentoo it probably wouldn't be me looking into it :) It's not out of malice or indifference that we don't do everything possible to support Linux variants...it's just a matter of time and resources. > My hope is to come back to you guys in a more constructive mood, bearing gifts > of patches etc and really get jruby to be bloody brilliant on gentoo. when I > get time. while there aint that many jruby related defects [5], some will be > difficult to fix. The unit tests failing being a good example > > So please talk to your local ubuntu/debian, fedora, ****gentoo**** > representative, get the distro's to be the main way you get jruby to the > masses. FWIW, we do have as part of our release cycle "inform linux dists about new JRuby release". It's not feasible for us to test for each Linux or to prepare our own packages for each right now. If there's more we can do (or ideally, a better way to do what we do already), we definitely want to help make JRuby on Gentoo (and every other Linux) be totally spectacular. - Charlie --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
