(EZ-89) For discussion - Install rubygems for jruby environment

[shrug]

This depends on the ezbake changes at puppetlabs/ezbake#358

This installs gems to the package buildroot using our vendored jruby. This is currently running with a sample set of gems that use native extensions.

We should discuss what gems we actually want installed, and validate that the install location is correct. The server config will presumably need to be updated to reference that gem path.

[scotje]

semantic_puppet and hocon were gems discussed in https://tickets.puppetlabs.com/browse/RE-7610

Also, do we want to be able to control the versions of the gems getting installed?

[cprice404]

@scotje I think this is just a POC to prove it out, and that we probably won't actually merge this PR. But, @shrug , I do think we will want to pin to specific versions of all the gems we install this way, so would be good to test that and sort out what the syntax would look like?

[scotje]

A possibility that could be implemented in just the shell:

puppetserver_gems=(
  'msgpack --version 1.0.0'
  'nokogiri --version 1.6.8'
  'fast_gettext --version 1.2.0'
)

for i in "${puppetserver_gems[@]}"
do
  java -cp puppet-server-release.jar clojure.main -m puppetlabs.puppetserver.cli.gem --config jruby.conf -- install $i
done

[cprice404]

@shrug any thoughts on @scotje 's suggestion, or how we should specify version numbers for the individual gems?

Do you think we need to sort that out before getting puppetlabs/ezbake#358 in? Or are you confident that that PR won't be affected?

[shrug]

Yeah @scotje's suggestion is pretty much in line with what I was thinking as well.

As far as the ezbake change, I'm considering removing all of that and just adding java as a build dependency across the board to keep it simple. I'll put a second PR up against ezbake with to compare shortly.

[shrug]

Submitted puppetlabs/ezbake#359 as a comparison. Either one will work. If we go with puppetlabs/ezbake#359, I'll just need to update this PR to remove the build-dependencies lines from ezbake.conf

[shrug]

Updated to incorporate installing specific gem versions.

Until we figure out the specific set of escape magic to get the multiline bash stuff working, this is just executing the gem install for each gem.

Also updated to work with puppetlabs/ezbake#359

[shrug]

puppetlabs/ezbake#358 landed, so this needs to be updated back to that style.

@scotje or @cprice404 do you want me to update this, or do you have what you need to start moving forward?

[cprice404]

Hmm, do you still have that commit in your history, @shrug ? If so it'd be awesome if you could switch this back, otherwise we can figure it out when we get there.

@scotje we will need to do a release of ezbake before those changes can be consumed, and we need to wait for @camlow325 's final HUP-related PRs to land before we do that.

[shrug]

No worries, I'll change this back to the previous version in just a bit

[scotje]

Cool, @cprice404 is that pending work just the EZ-99 and EZ-100 PRs?

Do we want to use this PR to bring in the actual gems we need at this point? (Once the new ezbake is released.)

[cprice404]

@scotje yeah I think EZ-99, EZ-100, EZ-101. As for which PR to use to bring in the actual gems, doesn't really matter to me whether it's this PR or a fresh one that uses this one as an example.

[cprice404]

@shrug I was going to work on this today; trying to cobble together the right build-deps for redhat/debian based on my limited knowledge but if you have that other commit around it'd be super helpful. Thanks!

[shrug]

Yep, sorry. I just pushed it up, it's b8821a9

[cprice404]

@shrug awesome, thanks.

[camlow325]

@shrug @cprice404 Should we close this in favor of #1227 now?

[cprice404]

Closed in favor of #1227.