my example was a bit mean since bundler or rubygems can NOT resolve such a conflict: xercesImpl version 3.2.0 in Gemfile and 2.9.0 in Nokogiri gem. maven can due to a different dependency resolution. so forcing maven artifacts to be resolved with rubygems/bundler is limited and such conflicts can occur anywhere in the dependency hull of an artifact.
maven also have the exclusion semantic which allows to reduce the dependency set of an artifact which gets used and this can lead to totally different results and even to unresolvable conflicts. yes, it is true one could use the mvn: notation for such jar dependencies. but as long neither rubygems nor bundler does support maven-gems probably I need to stick to tools which do and use gemspec as maven DSL. - Kristian On Tue, Nov 15, 2011 at 12:41 PM, Tobias Schlottke <tobias.schlot...@gmail.com> wrote: > Hi Kristian, > > > its my understanding that if nokogiri would name its mvn dependencies (in the > gemspec), > bundler would wipe out this problem and only one version of xercesimpl would > be active. > > The only problem left is that buildr (in my case) would use different gems. > This is no problem at all (for buildr). There could be an integration like > this: > > require 'buildr/bundler_support' > compile.with(from_gemfile) > > And that's it. > > But I understand your point: > Rubygems should be able to declare jar dependencies (which is possible > through the mvn: way) and an API to get out the dependencies with > whatever-build-tool you're using, right? > This would be pretty easy to add to the current implementation, as far as I > see this. > > Best, > > Tobias > > > > Am 15.11.2011 um 08:02 schrieb kristian: > >> 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 >> >> > > > --------------------------------------------------------------------- > 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
