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


Reply via email to