On Mon, Feb 1, 2010 at 1:34 PM, kristian <[email protected]> wrote:
> so I try to describe the problem with sample:
>
> the setup of three artifacts
> com.play.one - there two version 1.1 and 1.2
> com.play.two-1.0-java - depends on com.play.one-1.1
> com.play.three-1.0-java - depends on com.play.one-1.2,com.play.two-1.0-java
>
> make a gems out of them - use my code here and I use dependency with
> equals to the exact version (as the pom does)
Is this something you were able to actually set up or is this
hypothetical? If it's something you were able to set up, how are you
mapping maven stuff to rubygems? Or perhaps you just simulated this by
manually generating some gems?
> jruby gives me in jirb:
> require 'com.play.three'
> Gem::LoadError: can't activate com.play.one (= 1.1, runtime) for
> ["com.play.two-1.0-java", "com.play.three-1.0-java"], already
> activated com.play.one-1.2-java for ["com.play.three-1.0-java"]
This does seem like a bit of an edge case, but it's one we probably
need to address. In the current server, installed gems specify gem
dependencies as follows (an example from the org.apache.ant.ant maven
gem):
s.add_dependency(%q<org.apache.ant.ant-launcher>, ["~> 1.7.1"])
s.add_dependency(%q<xerces.xercesImpl>, ["~> 2.9.0"])
s.add_dependency(%q<xml-apis.xml-apis>, ["~> 1.3.04"])
The ~> means "approximately greater than" as described here:
http://docs.rubygems.org/read/chapter/16#page76
I believe this would allow the 1.2 library to satisfy the 1.1 library,
but maybe you could experiment with it and see? I'm also not sure how
far "approximately" goes...
- Charlie
> maven does the following
> DEBUG] com.play:three:jar:1.0-SNAPSHOT (selected for null)
> [DEBUG] com.play:one:jar:1.2:compile (selected for compile)
> [DEBUG] com.play:two:jar:1.0-SNAPSHOT:compile (selected for compile)
> [DEBUG] com.play:one:jar:1.1:compile (removed - nearer found: 1.2)
> [DEBUG] junit:junit:jar:3.8.1:test (selected for test)
> [DEBUG] Plugin dependencies for:
>
> everything install nicely but I can not use them :-(
>
> I would suggest to use instead of equals to the version you use
> something like equals or bigger the pom-version and smaller the next
> major version. maven allows such version ranges. that should be OK if
> artifact follows the maven versioning - I guess.
>
> with regards
> Kristian
>
>
>
>
>
>
> On Mon, Feb 1, 2010 at 9:39 PM, Charles Oliver Nutter
> <[email protected]> wrote:
>> On Thu, Jan 28, 2010 at 7:33 AM, kristian <[email protected]> wrote:
>>> hello,
>>>
>>> I have two thoughts about this. first one is more curiosity how this was
>>> solved:
>>>
>>> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Transitive_Dependencies
>>> defines the "nearest definition". so in case the complete dependency
>>> tree has two version of the same jar it chooses one. how is the
>>> behavior mapped to rubygems since such a version resolution does not
>>> exist there?
>>
>> I believe in the current server it would end up just walking the first
>> such dependency it encounters, but I don't think we can rule out the
>> possibility that it might install both versions. I have not
>> checked...it's open for discussion.
>>
>>> second thought is:
>>> my world of using ruby is basically rails with jruby and when I want
>>> to deploy a rails application I would like to share as many
>>> libraries/jar with all applications and do not repeat the same jars
>>> for each application in WEB-INF/lib. typical example are the jdbc
>>> drivers, the moment I use gems there is no way to share them anymore.
>>> in data_objects (from datamapper) we do not require the jdbc-gem when
>>> the respective jdbc driver is already in the classloader which allows
>>> this kind of sharing the jdbc jars via the application server/servlet
>>> engine.
>>>
>>> with datamapper we also experienced a classloader issue when the it
>>> runs inside a webcontainer: when you get the jar as gem (via require
>>> the respective gem) you can not use
>>> Thread.currentThread().getContextClassloader() to load the jdbc driver
>>> but need to use getClass().getClassloader() to load it. so here your
>>> code behaves differently whether it comes from a jar or from a gem -
>>> hmm. maybe that is more a jruby classloader issue then a gem wrapper
>>> of jar issue.
>>
>> Yes, this is also an open question. Right now jar files are nicely
>> loadable for Ruby code, but there's challenges to having the same
>> mechanism work when the host JVM has already loaded those jars through
>> another mechanism. One way might be to search the current classpath
>> for those jars, but that's not reliable in cases where those jars are
>> from a non-system classloader. Typical Java applications handle this
>> in a very simple way: they basically don't allow dynamic runtime
>> loading of jars at all, instead expecting that you'll set up
>> classloaders/classpaths outside the execution of your application.
>> That doesn't seem like a great option either.
>>
>> Open for dicussion :)
>>
>> - Charlie
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>>
>>
>>
>
>
>
> --
> Kristian Meier + Saumya Sharma + Sanuka Meier
> Vadakkethu House,
> Edayanmula West PO - 689532,
> Pathanamthitta District, Kerala, INDIA
>
> tel: +91 468 2319577
>
> protect your privacy while searching the net: www.ixquick.com
>
> _=_
> q(-_-)p
> '_) (_`
> /__/ \
> _(<_ / )_
> (__\_\_|_/__)
>
> ---------------------------------------------------------------------
> 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
