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
