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
