Support building a deployable and self-executable WAR file of Squash

[bjeanes]

Work:

• Create (optionally) self-executable WAR file
• Bundle assets into WAR file (relies on Asset precompilation woes #53)
• Make repo clone path (currently hardcoded to tmp/repos) configurable since this path is inside the WAR and doesn't accommodate multiple instances running simultaneously (awaiting merge in Make repository clone directory configurable. #61).
• Currently only rake sub-task works, get all bundler bin stubs executable from the WAR (see java -jar rails.war -S rake db:migrate jruby/warbler#136 and Support running executables from Bundler gems and project-local scripts jruby/warbler#141)
• warbler gem should only be in :development group only. See comment in Gemfile for why it currently is not. Tracked as Warbler bundles own gemspec, even when in an excluded bundler group jruby/warbler#142.
• Allow for configuration to be provided post-compilation so that production config details are not needed on developer/deployer machines or CI. This could be done a few ways (looking for input):
  • Adding an initializer that provides Configoro with an additional directory of configs to load (though this doesn't account for config/database.yml)
  • Adjusting Configoro's YAML loading to do ERB-interpolation (like Rails does) to provide config with Java properties or ENV vars
  • Teach Configoro how to be overridden by Java properties or ENV
  • Put an interface between config setting and config usage and have different adapters (ENV adapter, for example — useful for Heroku deployers)
  • Whatever comes out of Use ENV variables for configuration, more upgradable (and Heroku support) #36
  • Something much simpler that I am yet to think of, since known of the above solutions are silver bullets or clearly improvements.

[bjeanes]

This is to (eventually) account for bundling with --binstubs such that you can run any gem command from the WAR file by doing (for example): java -jar squash.war -S rails console. See jruby/warbler#136

[bjeanes]

@RISCfuture do you have any input for how you think configuration should be handled with the constraint of being able to be provided post-compilation?

I'm currently thinking that an initializer that can add an extra Configoro directory based on an environment variable and it will merge those in after all other configs have loaded. Therefore, something like CONFIG_DIR=/var/my-app/config java -jar my-app.jar could be used and I can manage those configs separately from the app repository and build process.

[RISCfuture]

I authored the Configoro gem so I'm happy to add runtime configuration directory support if that's the ideal way of doing it. Might be better than polluting the namespace with 100 environment variables.

[bjeanes]

Yeah I'd like to avoid that too. The simplest solutions are:

• adding extra directories at runtime, which should be doable with something like:

  Dir["#{ENV["CONFIG_DIR"]}/*.yml"].each { |f| Squash::Configuration << f }

• adding ERB interpolation a la Rails to allow users to use ENV vars directly, if they chose:

  database:
    production:
      username: <%= ENV["DB_USER"] %>
      #...

[RISCfuture]

I'd prefer the former approach as it allows the app to continue to work for people who do not wish to use ENV-based configuration.

[bjeanes]

Actually, both options should allow config as it exists today. In the latter case, it would simply let users interpolate values into their database.yml using ERB and draw the real values from any source (ENV is just an example, Java properties or shelling out are others). This is exactly how database.yml in Rails works today. All that is added is an ERB call between reading the file and parsing the yml. See here for how Rails does it: https://github.com/rails/rails/blob/9ee6f3cc8/railties/lib/rails/application/configuration.rb#L106

[bjeanes]

I'd actually vote for doing both of these things. Making Configoro more versatile and inline with Rails' regular .yml files, may have other positive outcomes too. Adding the extra directory means config can be kept in a separate location/repository, which is a major win because it means not having to fork Squash in anyway and allows keeping up to date frictionless.

The only ugly duckling here is database.yml, since Configoro does not control this. I think going with the Rails standard of checking in database.example.yml and git ignoring database.yml solves this for the most part, though.

[RISCfuture]

Squash uses JRuby at Square but we don't need Warbler; no reason we should have to install the gem. I'm facing a similar issue with Resque integration -- how can I avoid bundling the Resque gems for installs that don't use Resque? Bundler has no concept of an "optional" gem.

I need to come up with a comprehensive solution to this problem before we integrate too many optional third-party tools.

[bjeanes]

This makes a lot of sense. I'll think about it too. If I were in your position, I would investigate what it would take to make Squash a Rails engine such that people can simply include it as a gem into their own mostly empty Rails app and set up customizations from there. I'm going to investigate vendoring Square and mounting the Rails app into a small Rack app as is...

[RISCfuture]

Yeah there were a lot of suggestions about making Squash some kind of giant gem that gets included into an otherwise empty app, but I think that kinda obfuscates the implementation a bit and disincentivizes contribution to the web app.

[RISCfuture]

OK, the most recent commits added a decent (but not awesome) functionality for optional gems. Check it out!

[karthick086]

what is squash basic and dtd on xml pls sent me

[kirantpatil]

@bjeanes may I know about rails engine support work for squash? We were also thinking in the same line. Have you done anything so far ?

Thanks.