iconara / puck

98%

master: 99%

LAST BUILD ON BRANCH fix_12

branch: fix_12

CHANGE BRANCH

x

Reset

• fix_12
• bundler-workarounds
• everything-is-awesome
• exec
• explicit-prefix
• gemspec-in-gemfile
• master
• no-bootstrap-exit
• pr_4
• pr_5
• prefer-user-installed-gems
• set-dollar-zero
• tmpdir-build
• travis-bundler-versions
• travis-debug
• travis-test
• v1.0.0
• v1.0.0.pre4
• v1.1.0
• v1.1.1
• v1.1.2
• v1.2.0
• v1.2.1
• v1.2.2
• v1.2.3
• v1.2.4
• v1.2.5

Build # 76

Build Type

push

travis-ci

Committed by iconara

Commit Message

Work around an issue in Windows

`$: << File.expand_path('../../lib', __FILE__)` from an app's bin files does not work on Windows because the path ends up as "classpath:C:/META-INF/app.home/lib". It's the same on *nix but it doesn't seem to matter that the path is prefixed with just a slash.

The behaviour of File.expand_path seems to depend on not just the actual value of __FILE__, but also on how the file it's run from was loaded. That sounds very strange and I hope I'm wrong, but that's what it looks like. It does seem like when the file is loaded either as "classpath:META-INF/app.home/bin/foobar" or just "META-INF/app.home/bin/foobar" that the path returned by File.expand_path does not come out prefixed by "classpath:/", but instead a full file system + JAR path, e.g. /home/foo/bar.jar!/META-INF/app.home/lib".

I have not tested this on Windows, I'm hoping to get some help to verify that this works around the problem. The next step is figuring out how to report this as a JRuby issue.

Run Details

323 of 328 relevant lines covered (98.48%)

11.85 hits per line