so finally I got around and did my first gem with native-extension which
basically installs the declared jar dependencies. see
the simple gem has jar dependencies but does not vendor them. on install
of
the gem those jars will be installed in the local repository and then
required by the jar-dependencies gem (which just keeps track of version
conflicts)
the Rakefile setup task does that installing and it need ruby-maven
which
comes with jbundler already. ruby-maven is not a runtime dependency
since
is has nothing to do during runtime. it is only needed on install time
the jar-dependencies is not on rubygems.org yet and I want to wait for
some
more feedbaclk on all this.
Thought I would poke my head in on this, this is how the Naether[1] gem
(a Ruby wrapper for Aether) has been running for a long time. When the
Gem is installed it bootstraps itself by downloading the jar
dependencies for Maven’s Aether, starts up Aether, installs the jars
into the local maven repo. Then when the naether starts, it
automatically loads the Aether jars into the classpath.
thanx Michael. indeed I used solr-sail as blueprint today
-regards,
christian
On Thu, Jan 23, 2014 at 4:41 PM, Michael Guymon
<[email protected]mailto:[email protected]> wrote:
Thought I would poke my head in on this, this is how the Naether[1] gem
(a Ruby wrapper for Aether) has been running for a long time. When the
Gem is installed it bootstraps itself by downloading the jar
dependencies for Maven’s Aether, starts up Aether, installs the jars
into the local maven repo. Then when the naether starts, it
automatically loads the Aether jars into the classpath.
On 1/23/14, 5:28 AM, christian wrote:
so finally I got around and did my first gem with native-extension which
basically installs the declared jar dependencies. see
the simple gem has jar dependencies but does not vendor them. on install
of the gem those jars will be installed in the local repository and then
required by the jar-dependencies gem (which just keeps track of version
conflicts)
the Rakefile setup task does that installing and it need ruby-maven
which comes with jbundler already. ruby-maven is not a runtime
dependency since is has nothing to do during runtime. it is only needed
on install time
oogles your code You may find it useful to use Naether for pom-loader.
That way you can resolve the jar dependencies of a pom without having
Maven installed, then the gem will work out of the can. Naether uses the
same Aether lib as Maven, so it will (should?) get the same jar results.
On 1/23/14, 11:52 AM, Patrick R. wrote:
There’s also:
It reads from your pom.xml directly and puts all the jars it finds on
the class path.
thanx Michael. indeed I used solr-sail as blueprint today
-regards,
christian
On Thu, Jan 23, 2014 at 4:41 PM, Michael Guymon
<[email protected]mailto:[email protected]> wrote:
Thought I would poke my head in on this, this is how the Naether[1] gem
(a Ruby wrapper for Aether) has been running for a long time. When the
Gem is installed it bootstraps itself by downloading the jar
dependencies for Maven’s Aether, starts up Aether, installs the jars
into the local maven repo. Then when the naether starts, it
automatically loads the Aether jars into the classpath.
On 1/23/14, 5:28 AM, christian wrote:
so finally I got around and did my first gem with native-extension which
basically installs the declared jar dependencies. see
the simple gem has jar dependencies but does not vendor them. on install
of the gem those jars will be installed in the local repository and then
required by the jar-dependencies gem (which just keeps track of version
conflicts)
the Rakefile setup task does that installing and it need ruby-maven
which comes with jbundler already. ruby-maven is not a runtime
dependency since is has nothing to do during runtime. it is only needed
on install time
oogles your code You may find it useful to use Naether for pom-loader.
That way you can resolve the jar dependencies of a pom without having
Maven installed, then the gem will work out of the can. Naether uses the
same Aether lib as Maven, so it will (should?) get the same jar results.
The LockJar[1] gem is built on top of Naether to provide easy access of
jars to ruby. To download and get the paths of a jar and all its
dependencies, you can do the following:
paths = LockJar.list( :resolve => true, :local_paths => true ) do
jar
‘org.eclipse.jetty:example-jetty-embedded:jar:8.1.2.v20120308’
end
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
you want.
paths = LockJar.list( :resolve => true, :local_paths => true ) do
pom 'path/to/pom.xml'
end
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
with jars:
LockJar.load( :resolve => true) do
pom 'path/to/pom.xml'
local "org.apache.mina:mina-core:2.0.4",
“lib/mina-core-2.0.4.jar”
end
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 -
every of those projects have their own little pros and cons. but we all
agree that if every gem in the end just required their jars conflicts
are
bound to come.
for that the idea of GitHub - mkristian/jar-dependencies: manage jar dependencies for ruby gems it
just
tracks the requiring of jars and I am pretty sure LockJar and PomLoader
can
use that require_jarfile. the second aspect about adding jars to gem is
secondary (though it is just couple of lines code to do it).
it has one purpose to NOT load jars with different version into the
jruby-classloader (require jarfile) and warns the user. i.e. you can
find a
way on how to solve the version conflict or maybe it is just OK to
ignore
it.
so please remark on jar-dependencies and whether you want to support it.
I
will try to get the jruby team using it for the defaults gems (with
jars)
coming through jruby itself and I will contact torquebox about this as
well
and add the support to jruby-maven-plugins torquebox uses to build (some
of) their gems. and finally will try to get it into rake-compiler gem
(somehow since it will get some refactoring soon/already)
if you think of any improvements just let me know, i.e. something like a
finer switch than turn off ALL jar loading or allow ALL.
On Sat, Jan 25, 2014 at 6:34 AM, Michael Guymon [email protected]wrote:
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.
managing gems with maven (or ruby-maven) deals that maven will resolve
those gems and its transitive dependencies. it will also resolve
declared
jars (via the requirements fields of the gemspec) they will be all
resovled
even from jars which are declared inside a gem of a gem. but for this
you
need to add gem-maven-extension (part of the GitHub - torquebox/jruby-maven-plugins: maven plugin to handle rubygems in a maven way. including support for rspec, rails, cucumber, rake, etc set of plugins).
actually
torquebox itself uses it to create some of their gems and it also can
include jar dependencies.
actually jbundler and ruby-maven just declare some POM using the ruby
DSL
from ruby-maven and execute that POM (a phase or goal). most of the code
is
rather brief since it reuses the big set of existing maven plugins, i.e.
jbundler uses the maven-dependency-plugin to lockdown the jar
dependencies
After reading your responses I realize there was a typo in my original
question. My intention was to ask about gems that require jars using
maven.
E.g. foo.gem requires guava.jar but bar.gem requires foo.gem and also
makes use of guava.
Should I require guava in foo.gem?
Also re: system scope; I like being able to have maven resolve and
download the dependencies for me at install time. I believe that system
scope would require that I include the jars in my source code
repository, which is what I am trying to avoid.
Perhaps what I should do is lay out my use case and get some feedback
from you guys at what should be a sensible approach.
My application is delivered using RPMs. When we assemble our project we
use bundler in standalone to install gems in vendor/gems. All of our
application logic is written in gems and many of them make use of other
java libraries, which usually includes jars in their lib directory.
I want to move away from that model and use maven just as I have on
other java projects.
I wonder if I should treat these dependencies the same way that some
YARV gems do; make all dependencies “provided” scope when authoring gems
and then require the applications that use my gems and then install the
jars in the vendor/jars directory?
After typing that, it reads awful.
Curse you dependency management!
Thanks,
Ariel
Sent from my mobile device. Please excuse any errors.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
