update jruby jar to 1.7.15
pinned i18n dependency and cosmetic cleanups
new generated Gemfile lock
refactor gem bundling using stadalone setup & use standard Gemfile with gemspec
update to jruby 1.7.16 and remove jar-dependencies, bouncy-castle-java, jruby-openssl from gemspec
get ready for future plugins mechanism
deprecated USE_JRUBY environment var
added USE_RUBY and USE_DRIP environment vars
centralized gem path handling in LogStash::Environment
use consistent discovery strategy
When using bundler's "gemspec" setting it hardcodes a
local path as the "remote". This causes every 'bundle install' or
similar invocation on any other workstation to change that file simply
because the remote has changed. Not good.
Work around it by evaluating the gemspec ourselves and generating the
gem dependency list from that.
Same effect, better result, I think.
'bundle install' when already installed should be faster than the
previous gembag. More importantly, it is also more accurate in terms of
dependencies.
Bonus points that we can do 'clean' which will purge any unknown gems
and keep our gems directory nice and tidy.
The main purpose is to speed up repetitive build invocations. Bundler's
dependency resolver is better than that of the previous gembag.rb, and
its 'clean' feature lets bundler manage the gems listing - even between
builds. This lets not have to 'rm -rf vendor' between builds on jenkins
to ensure quality testing :)
Other changes:
- Hide the Gemfile and Gemfile.lock in the 'tools' directory. This
should hopefully prevent users from accidentally updating these files
and thus avoiding merge conflicts later.
- Minor patch to use RbConfig::CONFIG['ruby_version'] instead of
RUBY_VERSION. Confusing, I know. The former is the 'ruby abi' version,
it seems, and the latter is the actual ruby implementation version.
Example, on MRI 1.9.3, the former is 1.9.1 and latter is 1.9.3. On
JRuby, the former is 1.9 and latter is 1.9.3. COMPUTERS. HELP.
