- the DSL mimics the one from bundler
- you can use maven like version declaration or rubygems/bundler like version ranges
- it locks down the versions like bundler inside "Jarfile.lock"
- you can declare jar dependency within a rubygems using the requirements directive of the gem specification. jbundler will include those jar dependencies into its classpath
- on the first run everything get resolved, any further run just the setup of classpath is done (without any maven involved)
- it integrates nicely with bundler when Bundler.require is used
just add it as first entry in your Gemfile (pending since no gem is released)
such bundler config will trigger the classpath resolution on the first call of
Bundler.require, any successive runs will reuse the classpath from .jbundler/classpath.rb without any more action with maven.
if you use only rubygems or isolate then following require will trigger the classpath setup
please first build the jar file for the jbundler gem, see Build.md.
example/my_project has a Gemfile which uses a gem which depends on jar dependency. see example/gem_with_jar/gem_with_jar.gemspec how the jar gets declared.
execute example/my_project/info.rb to see it in action:
cd example/my_project jruby -S bundle install jruby -S bundle exec info.rb
update of single artifacts is not possible.
since the version resolution happens in two steps - first the gems then the jars/poms - it is possible in case of failure of the second one there could be another set of versions for the gems which would then succeed the jars/poms resolution. but there is plenty of possible ways to improve this (maven could resolve the gems as well, etc)
Jarfile is not a DSL, i.e. it is not ruby though it could use a ruby DSL to read the data (any contribution welcome).
jbundler does not obey the $HOME/.m2/settings.xml from maven where you usually declare proxies, mirrors, etc.
adding a maven repository
the maven central is default repostory and is always there. adding another repository use following decalration
repository :first, "http://example.com/repo" source 'second', "http://example.org/repo" source "http://example.org/repo/3"
a pom dependency is not associated with a jar file but has dependencies to other poms or jars.
dependencies can be declared either in Jarfile
jar 'org.slf4j:slf4j-simple', '> 1.6.2', '< 1.7.0' jar 'org.sonatype.aether:aether-api', '1.13'
or inside the gemspec through the requirements (see also the example directory of this project):
Gem::Specification.new do |s| s.name = 'gem_with_jar' s.version = '0.0.0' s.requirements << "jar 'org.slf4j:slf4j-api', '1.5.10'" end
maven like version
jar 'my.group.id:my-artifact-id', '1.2.3'
this will add the jar dependency for the maven artifact my.group.id:my-artifact-id with version 1.2.3. this version will be treated as maven version, i.e. in case of a version conflict the one which is closer to project root will be used (see also: TODO link)
rubygem like version
some example (see also: TODO link)
jar 'my.group.id:my-artifact-id', '1.2.3' pom 'my.group:my-artifact-id', '=1.2.3' jar 'my.group.id:artifact-id', '>1.2.3' jar 'my.group:artifact-id', '>1.2.3', '=<2.0.1'
the no version will default to [0,) (maven version range) which is >=0 in the rubygems world.
the not version !3.4.5 can not be mapped properly to a maven version ranges. >3.4.5 is used instead in these (rare) cases.
update of a single artifact is not possible (yet). but to update the whole set of artifacts just delete the lockfile Jarfile.lock
if jbundler sees that Gemfile.lock or Jarfile is newer then the .jbundler/classpath.rb file then jbundler tries to gracefully upgrade towards the changes. the is a maven-like behaviour and once there are command line tools for jbundler they can behave like bundler.
bug-reports and pull request are most welcome.