Seems like the root cause is that my JarDirectoryResource listFiles implementation was faulty. Should be fixed now.
I had to update the test to expect some "phantom" directory entries when dealing with jars. However, that's behavior that is identical to as if the jar were extracted. For example, if jar contained file "foo/bar.txt" the Dir["...jar!*/"] now correctly returns both .jar!/foo and .jar!/foo/bar.txt entries, since if extracted, foo/ directory would be created.
This should fix #1453 for real now.
@ratnikov This appears to fail the new spec you updated (your expectation looks correct) as it appears to not find /glob_target on master. I would land this as-is but we are matching too much right now which may be better than too little?
Fix the JarDirectory resource to return proper sub-files.
This also includes "phantom" jar directory entries, even if a zipfile directory entry does not exist.
Now that regular file globbing handles jar entries well, no need for …
…special parsing logic
Duh! Fixed by making RubyDir.aref just use general glob_helper logic now.
jar_glob_spec now passes fully (and this time I didn't keep a lingering -e flag that was skipping tests either)
By the way, spec:ci_interpreted_travis passes for me locally, so I'm not sure what's up with travis.