Merged
Conversation
Member
|
@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? |
added 2 commits
February 1, 2014 19:32
This also includes "phantom" jar directory entries, even if a zipfile directory entry does not exist.
…special parsing logic
Contributor
Author
|
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) |
Contributor
Author
|
By the way, spec:ci_interpreted_travis passes for me locally, so I'm not sure what's up with travis. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.