Comments below . . .
On 1/25/14, 12:02 AM, Ariel V. wrote:
Patrick and Michael,
pom-loader and LockJar both look interesting, thanks for sharing it. I
have questions for both or you…
When I add gems that also require gems does it make sense to also
declare those dependencies in the project pom?
I have never used gem deps in a Pom, Christian would know.
If I want to bundle jars in a local directory for my application, how
difficult is it to use copy-dependencies?
LockJar only uses the Aether framework for jar dependency graphing. It
does not have access to other parts of Maven, such compile, package,
etc. So you couldn’t trigger a copy-dependencies task from a pom with
LockJar. Spinning the concept around a little: from a pom, LockJar can
give you access to all the Jar dependencies and you can copy them where
paths = LockJar.list( :resolve => true, :local_paths => true ) do
As to local jars, if they are defined as system scope in the pom,
LockJar will pick them up. From the previous example, the local jars
path would be included in paths.
This is one of the areas Naether’s setup is different than standard
Maven. It allows system scopes dependencies to join in the resolution
from transitive dependencies. Naether checks relative to the current
work space if the system dep exist, if it finds it, it adds it to the
dependency resolution. If it does not find it, the dependency is ignored
(which is what Maven does). Basically, if you deploy a pom with system
scopes, LockJar will translate that to local paths as well.
I actually started working on local workspace resolution for Naether, so
that a local jar could override transitive dependencies. Was useful when
a dev copy of a jar should be used instead of the installed version. It
never made it out to LockJar tho, there is a placeholder in the dsl for
it. Here is an example of what I have in mind for loading the classpath
LockJar.load( :resolve => true) do
What do either projects do in cases where there are conflicts? e.g.
nokogiri including bundled xerces jar
Ah, the problem of a polluted classpath. Christian and I pondering this
for a little while, I never figured out a solution for it. The issues
are being able to know all the jar requirements of all gems at (before?)
runtime and being able to have a valid resolution for all those jar
requirements. If all gems with jars has some sort of spec (I only need
this jar at >= 1.0) a pre processor could run a generate a Jarfile.lock
with the runtime jars. A plugin for Bundler would be perfect . . . just
need Bundler to support plugin -
Hope these rambling answers help!