Warbler feedback

Ruby JRuby
1

Hi,

I don’t know if this is the correct place for this feedback, please
let me know if not.

We’ve recently released a Rails apps running under JRuby, and I’ve
some feedback stemming from our experience using Warbler for
deployment packaging. These are probably edge cases, but may be
worthwhile to someone. We also had some unusual demands, such as we
wanted to run the same app under Mongrel and Tomcat, Mongrel locally
and Tomcat in production, so I imagine someone using JRuby exclusively
may not have these issues.

  1. When installing warbler as a plugin, it uses the native (MRI) rake,
    which causes problems when non-native gems are used (e.g. hpricot) as
    they will be pulled in rather than the JRuby/Java version. You could
    pull in the appropriate JRuby gem into vendor, but then you’re stuck
    running under jruby and things won’t work under mongrel (not optimal
    for local development). The workaround is to install warbler as a gem
    under JRuby, install the required gems under MRI and JRuby, and build
    the war file under JRuby. This isn’t ideal as you’d like to pull all
    dependencies into vendor if possible.

  2. Overriding the libs by placing them into lib/java/ and setting
    config.java_libs = FileList[“lib/java/*.jar”], then bundles the JARs
    twice, once as you set them explicitly, then again as it bundles
    everything under lib. Warbler should exclude these if they’re already
    bundled.

  3. Log files (log/*) are included by default, they should be excluded.
    This caused us quite a bit of grief as our ops guys were looking at
    old (developer) log files, thinking they were local to the staging
    machine. Solution is to explicitly exclude log files.

  4. Rspec and testing plugins are included by default, not sure what to
    do about this as there may be a time when you’d want them included at
    runtime. Maybe documenting this explicitly would be fine. Workaround
    is to explicitly include them.

  5. Using warbler as a plugin, and building a war with rake pulls in a
    bunch of gems even when they aren’t required, such as rake. Solution
    is to remove the plugin and go back to the gem.

Hope this is helpful to someone.

Cheers,
Tom

tom adams
e:tomjadamsgmail.com

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
2

On Mon, Jul 14, 2008 at 8:30 PM, Tom A. [email protected] wrote:

Hi,

I don’t know if this is the correct place for this feedback, please
let me know if not.

This venue is fine for now. I hope to set up some mailing lists and
bug tracking for Warbler in the near future.

We’ve recently released a Rails apps running under JRuby, and I’ve
some feedback stemming from our experience using Warbler for
deployment packaging. These are probably edge cases, but may be
worthwhile to someone. We also had some unusual demands, such as we
wanted to run the same app under Mongrel and Tomcat, Mongrel locally
and Tomcat in production, so I imagine someone using JRuby exclusively
may not have these issues.

We also run our Rails app with MatzRuby/Mongrel, JRuby/Mongrel, and as
a war file (in Glassfish). So you’re not alone.

  1. When installing warbler as a plugin, it uses the native (MRI) rake,
    which causes problems when non-native gems are used (e.g. hpricot) as
    they will be pulled in rather than the JRuby/Java version. You could
    pull in the appropriate JRuby gem into vendor, but then you’re stuck
    running under jruby and things won’t work under mongrel (not optimal
    for local development). The workaround is to install warbler as a gem
    under JRuby, install the required gems under MRI and JRuby, and build
    the war file under JRuby. This isn’t ideal as you’d like to pull all
    dependencies into vendor if possible.

You should also be able to run rake within JRuby to create the war
file when warbler is installed as a plugin. We do this as our staging
servers don’t actually have MatzRuby installed on them at all.

You can already specify gem versions to bundle, but it seems like it
would be nice to specify platform as well, or run in such a way that
the platform used is java/jruby. Not sure if this is possible with
Rubygems. Noted.

  1. Overriding the libs by placing them into lib/java/ and setting
    config.java_libs = FileList[“lib/java/*.jar”], then bundles the JARs
    twice, once as you set them explicitly, then again as it bundles
    everything under lib. Warbler should exclude these if they’re already
    bundled.

Noted.

  1. Log files (log/*) are included by default, they should be excluded.
    This caused us quite a bit of grief as our ops guys were looking at
    old (developer) log files, thinking they were local to the staging
    machine. Solution is to explicitly exclude log files.

Noted. I’ve already noticed this myself, and already have a task item
to exclude log files.

  1. Rspec and testing plugins are included by default, not sure what to
    do about this as there may be a time when you’d want them included at
    runtime. Maybe documenting this explicitly would be fine. Workaround
    is to explicitly include them.

We have explicit excludes for RSpec. I think you’re right that
documentation is the best approach.

  1. Using warbler as a plugin, and building a war with rake pulls in a
    bunch of gems even when they aren’t required, such as rake. Solution
    is to remove the plugin and go back to the gem.

Rails has a dependency on Rake, and so it gets pulled in by Rubygems.
If you try to exclude it, I’m pretty sure you’ll break things because
Rubygems complains loudly if it can’t activate a dependent gem. Rake
is pretty small, so I’m not personally worried about the overhead.

Hope this is helpful to someone.

Indeed, thanks for taking the time to write up your feedback. Let me
know if you have any pie-in-the-sky ideas for how to make things
easier.

Cheers,
/Nick

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email
3

Indeed, thanks for taking the time to write up your feedback. Let me
know if you have any pie-in-the-sky ideas for how to make things
easier.

Thanks Nick, not really too much, just more documentation, maybe some
common use cases would be good. Also, getting the plugin to work
looked easy, but had some side effects, which made it harder to use
then the gem.

Appreciate your work, the least I can do is give feedback :slight_smile:

Cheers,
Tom

tom adams
e:tomjadamsgmail.com

To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email