first I need to point you to http://jpkutner.blogspot.com/2011/04/ease-of-bundler-power-of-maven.html
the author has bundler integration. I guess my last point to Nick email is to point out problems like: Gemfile: source :rubygems gem 'nokogiri' gem 'mvn:xerces:xercesImpl', '3.1.0' with such a Gemfile you will end up with two xercesImpl in the classpath with two different versions which can lead to all kinds of problems - whenever you have two versions of the same library in the classpath. the same holds true if I want to use nokogiri in javaproject where I need some xercesImpl on the java side as well. there is a good reason why gems do NOT vendor all their dependencies BUT jruby-gems DO vendor all their jar dependencies. my point is that rubygems NEEDS a way to declare jar dependency. ruby-maven proposes a way to do so. whether this gets implemented via maven or aether that is a implementation detail. currently the maven integration of rubygems uses (ruby-)maven, but IMO these maven-gems are going into the wrong direction and will just lead to classloader problems here and there. I hope I was able to convey my point :-) - Kristian PS ruby-maven the major tool for using my rails-gwt project: https://github.com/mkristian/rails-resty-gwt On Tue, Nov 15, 2011 at 11:42 AM, Tobias Schlottke <tobias.schlot...@gmail.com> wrote: > Hi, > > I've seen Kristians blogpost and I greatly appreciate his work. > I already thought about writing him a personal email before writing to this > list. > As I'm using Buildr, I wanted an build system independent solution. > I like the way jars are installable by default, even if it seems rather > "Hackish" at the moment. > > In my opinion (as a ~1 Month user/dev) this is one of the rough edges in > jRuby and should be solved with high prio. > Having no simple wan to handle this all is dangerous and I like the bundler > way, because it is simplest next step for all users coming from ruby. > Using maven or any wrapper for it feels a bit strange. The moment I > discovered Buildr was a pretty happy one ;) > > Kritistian, your solution is nice. IMHO it would be a bit better we had a > 100% integration with less visible maven stuff and make the process work > seamlessly with ruby tools (as the "official" rubygems hack does). > I understand your argument regarding ruby gems updates but IMHO it should be > no big deal to "inject" the patches as monkeypatch rather than patching > rubygems directly. > IMHO the rubygems patch grabs this problem at the right point: at its roots. > If you want to support something like this, it is a better way to go for the > root rather than offering a tool which makes it possible through injecting > something somewhere. > I must admit that - at this point - my extension of this hack is no better > (as it requires an index file) but I could imagine building a web service for > it, if it is really the way to go. > > IMHO there should be an official jRuby decision/way to go for this issue. > > Best, > > -Tobias > > > > > Am 15.11.2011 um 06:23 schrieb kristian: > >> maybe, not sure if aether is really sufficient. probably it is enough >> for something like adding >> >> jar 'slf4j:simple', '2.6.2' >> >> in your Gemfile and let aether resolve all deps for it. >> >> but I would like at put one more feature of ruby-maven into the discussion: >> >> you can declare jar-dependencies in your gemspec using the >> requirements like inhttp://rubygems.org/gems/nokogiri-maven it has >> >> s.requirements = ["jar 'msv:isorelax', '20050913'\njar >> 'thaiopensource:jing', '20030619'\njar 'nekohtml:nekodtd', >> '0.1.11'\njar 'net.sourceforge.nekohtml:nekohtml', '1.9.15'\njar >> 'xerces:xercesImpl', '2.9.0'\njar('org.jruby:jruby-complete', >> '1.6.4').scope :provided\n"] >> >> this ruby-maven uses to build up the classpath. so it is also an >> "extension" of gemspec. maybe that can be also implemented with the >> help of aether but I do not know. >> >> - Kristian >> >> On Tue, Nov 15, 2011 at 9:32 AM, Nick Klauer <kla...@gmail.com> wrote: >>> Has anyone looked at the Sonatype Aether >>> plugin(http://aether.sonatype.org/)? I've been following along with >>> Clojure's Leiningen project, and they are moving their own system to using >>> Aether for dependency management, as it handles all of the Maven settings, >>> proxies, repository/dependency resolution, etc. that they've hacked together >>> using Maven Ant Tasks currently. If all that is needed for Bundler >>> integration is a dependency resolution mechanism for Java libs, I would >>> think Aether could work, but I'm speculating quite a bit here. >>> >>> -Nick Klauer >>> >>> >>> On Mon, Nov 14, 2011 at 21:13, kristian <m.krist...@web.de> wrote: >>>> >>>> hi, >>>> >>>> first I need to express my point of view about jruby and >>>> classloaders/classpath, etc and that I did in blog post of mine: >>>> >>>> >>>> http://blog.mkristian.tk/2011/09/jruby-and-rubygems-and-javaclassloader.html >>>> >>>> sonatype.org worked on a nexus plugin which can offer a maven >>>> repository as rubygems-repository. the plan was to offer this for >>>> maven-central but it is not sure whether that ever materializes. but >>>> the plugin works (might run into inode problems on ext3 filesystem or >>>> maybe other FS when mirroring): >>>> >>>> https://github.com/sonatype/nexus-ruby-support >>>> >>>> in case you want to submit an issue do it on my fork >>>> https://github.com/mkristian/nexus-ruby-support/issues >>>> >>>> maven-gem support in jruby is not really ready for production: >>>> >>>> * any update of rubygems will wipe it out completely >>>> * dependency resolution of rubygems and maven differ which results in >>>> different set of jars which are used. >>>> * there are maven artifacts which depends on the JVM you are using and >>>> "dispatch" to the JVM dependent jar >>>> >>>> ruby-maven tries to be an extension for bundler which deals with jar >>>> dependencies which removes all the above short comings. when you use >>>> the bin-stubs from ruby-maven (which are located in ./target/bin) then >>>> you can use all your ruby commands with a classloader setup with your >>>> jar dependencies and maven did do the dependency resolution, i.e. >>>> exactly those jars are used which the pom files declared. >>>> >>>> the idea of "ruby-maven is for jars and bundle is for gems" is pretty >>>> new so any feedback is more then welcome ! >>>> >>>> regards, >>>> Kristian >>>> >>>> On Mon, Nov 14, 2011 at 9:54 PM, Tobias Schlottke >>>> <tobias.schlot...@gmail.com> wrote: >>>>> Hi there, >>>>> >>>>> I recently had some problems with jar dependencies in jRuby and tried to >>>>> find the most elegant solution. >>>>> IMHO the "gem install mvn:" feature is brilliant. >>>>> The only missing thing is bundler support. >>>>> Bundler is not able to find the gems because they're not included in the >>>>> #list result, which is the actual problem: >>>>> As far as I understood maven, it is not possible to list all jars in a >>>>> maven repo. >>>>> >>>>> So my question is: >>>>> Is anybody working on this topic? >>>>> IMHO there should be a way to inject a list of artifacts or a project >>>>> with the goal to build a central index. >>>>> Builder is the best way to resolve and handle those dependencies. >>>>> >>>>> What do you think? >>>>> >>>>> Take a look at what I did so far: >>>>> https://github.com/tobsch/maven-rubygems >>>>> >>>>> I know that this is pretty dirty but I wanted to get a feeling for your >>>>> opinion on this first. >>>>> >>>>> Best, >>>>> >>>>> Tobias >>>>> --------------------------------------------------------------------- >>>>> 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
