hi all, I was thinking about what was said on that thread a bit.
one point from Tobias was standard tools. if I look how I work currently then I use $ rake db:migrate $ rails server $ rspec spec/*_spec.rb etc and all these commands do have a nice clean java-classpath. the only thing which is different is (instead of bundle install) $ rmvn bundle install which does setup the classpath of the "locked" set of gem artifacts. this "locked" is important otherwise it is not possible to calculate the classpath in maven manner. the other difference between "rmvn" and the mvn:groupId:artifactId gems is that I do not use the gem-dependency declaration of rubygems. the reason are * classifier of an artifact * the gem-version has a very strict definition and maven uses a version can be almost everything. for example the jruby-core maven artifact uses a maven artifact with classifier 'native' and can not work with the current rubygems. I do have more artifacts which do not work because the dependency resolution is INCOMPATIBLE. if the idea was to get bundler to the classpath thingy then you would have me on board (with a huge amount of excitement). rubygems as standalone has lots of problems which led to tools like bundler which are able to rectify most short coming. using rubygems as "package description" for a library seams OK. beside one point I do agree with Tobias but to solve the problem for me bundler is the starting point and NOT rubygems. actually I am quite happy with the current situation since it would make managing rubygems with maven really nasty with the current approach. next version of maven hopefully comes with some native (j)ruby support but that will be less useful when it is not possible to integrate these two world properly. regards, Kristian On Thu, Nov 17, 2011 at 12:24 PM, Tobias Schlottke <tobias.schlot...@gmail.com> wrote: > Hi Nick, > I'll work something out. > The problem is for sure the lack of time, but I'll as Kristian if he's > willing to join. Could make more sense to work on one solution :) > I'll drop you a mail as soon as I'm sorted. > Best, > T* > Am 15.11.2011 um 20:48 schrieb Nick Sieger: > > Tobias, it would be great if you could look into this more. > You could start by spiking a refactoring of our fork of > rubygems: https://github.com/jruby/rubygems > Note that the JRuby changes are merged into version-specific branches called > jruby-rubygems_x_y_z for each version of rubygems that we've integrated. The > master branch is currently identical to upstream. > If you could give us a sketch of what you're thinking I'd be happy to go > lobby for the structural changes upstream. > Thanks! > /Nick > > On Nov 15, 2011, at 2:18 AM, Tobias Schlottke wrote: > > Hm, IMHO it would be better to switch away from "mvn:" to "jar:" to make it > build system independent. > 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? > > 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
