On Tue, Nov 15, 2011 at 1:48 PM, Tobias Schlottke <tobias.schlot...@gmail.com> wrote: > Hm, IMHO it would be better to switch away from "mvn:" to "jar:" to make it > build system independent.
:)) moving from mvn: to jar: is a good idea to hide the bad taste people have when reading maven !!!! > After that, rubygems should be patched to support different resolving > backends. > By default it should come with one which is able to install normal gems which > could be replaced by a JRubyMavenBackend, a JRubyBundlrBackend etc. > This would be a more elegant approach and - if the backend patch - is > accepted and a stable api would be found, would lead to 100% compatibility > for new rubygems versions… > > What do you think about this? > yes - I do agree with you and I am happy to hack the JRubyMavenBackend together using a maven resolution algorithm. not sure about the rubygems project whether they are open to such things. the past was rather disappointing though I do not know any details. regards, Kristian > Best, > > Tobias > > Am 15.11.2011 um 09:06 schrieb kristian: > >> 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 >> >> > > > --------------------------------------------------------------------- > 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
