File.expand_path with uri:classloader still relative on Windows #4418

Closed
jasonrclark opened this Issue Dec 31, 2016 · 11 comments

Projects

None yet

3 participants

@jasonrclark

I'm seeing differences in behavior for File.expand_path between Unix and Windows with file paths within a warbler-generated gem (using the uri:classloader prefix on files). On Windows, it doesn't resolve the relative components as expected.

Environment

C:\> jruby -v
jruby 9.1.6.0 (2.3.1) 2016-11-09 0150a76 Java HotSpot(TM) Client VM 25.111-b14 on 1.8.0_111-b14 +jit [mswin32-x86]

C:\> uname -a
MSYS_NT-6.1 IE11Win7 2.6.0(0.304/5/3) 2016-09-09 09:32 i686 Msys

No activated gems or environment variables of interest, just running straight irb shows the problem.

Expected Behavior

Running on Windows with the following values:

irb(main):001:0> File.expand_path("../../../vendor/jface/*.jar", "uri:classloader:/gems/swt-4.6.1/lib/swt/full.rb")
=> "uri:classloader://gems/swt-4.6.1/vendor/jface/*.jar"

As expected, the relative components of the path are dropped out. This is the behavior on CRuby on *nix.

Actual Behavior

On Windows, the ..s remain even after expanding the path:

irb(main):001:0> File.expand_path("../../../vendor/jface/*.jar", "uri:classloader:/gems/swt-4.6.1/lib/swt/full.rb")
=> "uri:classloader:\\gems\\swt-4.6.1\\lib\\swt\\full.rb\\..\\..\\..\\vendor\\jface\\*.jar"

As on *nix, I expect expand_path to get rid of all those relative components.

(As an aside, tested briefly with CRuby on Windows (2.3.3), but the behavior is even stranger there with the result being: "C:/uri:classloader:/gems/swt-4.6.1/vendor/jface/*.jar"... but since the uri:classloader isn't commonly found on CRuby, I suspect it's not an issue there?)

This appears to be the root cause of shoes/shoes4#1351 by way of the swt gem

@jasonrclark jasonrclark referenced this issue in shoes/shoes4 Dec 31, 2016
Closed

Packaged app failure on Windows #1351

@enebo enebo added this to the JRuby 9.1.7.0 milestone Jan 3, 2017
@enebo enebo added the windows label Jan 3, 2017
@enebo enebo closed this in 0bfe15c Jan 3, 2017
@enebo
Member
enebo commented Jan 3, 2017

@jasonrclark heya..can you verify this is working. One odd thing about this fix is on windows we seem to change prefix to 'uri:classpath/' instead of 'uri:classpath//' to avoid some code pretending this is a UNC-style path. I added a spec for this next to another which tests this same logic for the single argument version of expand_path.

@mkristian I probably should have made a PR but can you look at this and give me a blessing?

@jasonrclark

Thanks @enebo! Will give it a try when I do some Shoes work next. 💖

@enebo
Member
enebo commented Jan 3, 2017

@jasonrclark if that can be in the next day or so it would make me happy since we really need 9.1.7.0 out this week. :)

@jasonrclark

@enebo Cool! Will try to make it tonight then.

@enebo
Member
enebo commented Jan 3, 2017

@jasonrclark thanks!

@jasonrclark

@enebo Hmm, so getting the same result, but my jar still has jruby-core-9.1.6.0-complete.jar embedded in it, which suggests maybe I'm getting the old version embedded by warbler.

Steps I followed:

  • Compiled JRuby via https://github.com/jruby/jruby/blob/master/BUILDING.md#building-commandline-jruby
  • Pointed rbenv at that version
  • From copy of shoes4 cloned from master, ran bundle install
  • Ran bin/shoes -p swt:jar samples/packaging/package_me.rb which results in a jar at samples/packaging/pkg/package_me.jar
  • Copied that jar over to the Windows machine in question and ran with java -jar package_me.jar

As mentioned, I suspect warbler is getting the older JRuby pieces, but I'm not quite sure how to coerce it into picking up the right ones to embed. Any pointers?

@mkristian
Member

@enebo regarding uri:classloader:/ vs uri:classloader://: both versions shall work from the URLResource point of view. the original idea was to have uri:classloader:// but there is some path normalization code used at various places which just reduces the // to /, i.e. when I hard code in JRuby or other projects uri:classloader paths then I use uri:classloader://. but the code detecting this prefix always needs to detect uri:classloader:/ as well. the +1 for the 0bfe15c

@enebo
Member
enebo commented Jan 4, 2017

@jasonrclark well you are beating me...I have:

  -rw-rw-rw-  13847137   4-Jan-2017  10:07:08  META-INF/lib/jruby-core-1.7.26.jar
  -rw-rw-rw-  10481921   4-Jan-2017  10:07:08  META-INF/lib/jruby-stdlib-1.7.26.jar

And no -complete at all in mine. I am at a total loss on how to run your example. I did try changing ruby-version to jruby-head hoping it would do something different.

@jasonrclark

@enebo Hmm, I think I might have a custom version of the furoshiki gem which Shoes uses for packaging on my local machine... which unfortunately is at home :(

When I get back tonight I'll cut an actual version so with the latest changes which bump to the new warbler, but you could try building and installing that from master and see if that improves the situation at all.

@mkristian
Member

we changed the names a bit between 1.7.x and 9.x.x.x so jruby-core-1.7.26.jar is the same as jruby-core-9.1.6.0-complete.jar

as far I remember warbler does pack all gems from the Gemfile. make sure you have jruby-jar as development dependencies not default group. same for the warbler gem as well as it comes with a dependency to jruby-jar.

@jasonrclark if this still does not help please report as I have seen this problems with extra jruby jars embedded before . . . .

@jasonrclark

Success! 🎉

Appears I was using a custom build of furoshiki @enebo, which explains your different results. Combine that with a snapshot of jruby-jars-9.1.7.0-SNAPSHOT plus a hacked local copy of warbler to use the prerelease jruby-jars gem (whew) and I managed to generate a jar that ran as expected on Windows.

I'd give this a huge 👍 from team 👟 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment