Ping @ratnikov.

this actual means that package goal of the gem-maven-plugin only works with jruby version 1.7.12 and older.

sigh Stupid gmail considering github updates as "Forum" >.<

I'll take a look at it on Monday. We definitely need to keep beefing out test suite to cover all these corner cases.

it look very much that there are still other problems around path strings which are actually jar:file: URI like jruby/jruby-openssl#11

another case where I got problems with this was dd52792
where sometimes it was a jar:file: and sometimes not. sometimes the jar:file: uri was escaped (toExternalForm()) and sometimes not.

@mkristian is it a good idea to hack around tests instead of 'em failing (and fixing the underlying issues) ?

@kares I see if I can get failing tests on travis pass the "gem install" problem of jruby-openssl

@kares I tried to configure the gem-maven-plugin not to use the latest 1.7.17-snapshot for installing the gems, but it is not possible since the plugin inherits the maven-project classloader (class-realm in maven speak) and here I need the latest jruby snapshot since this is one which gets tested. but probably I did not understood your question.

anyway the test are still failing - well not the tests but the setup of those tests.

regarding dd52792

yes that is a hack and should not reach the actual branch. but the problem is that the same path can have at least 3 different representations which are all treated OK. but in that test assumes there is only ONE representation. so the question is who they are represented internally and how they are detected when they come in as strings, like "/jruby-stdlib-1.7.17-SNAPSHOT.jar!/META-INF/" is this a jar uri or a path on the filesystem. it is definitely a valid path with a directory having a name ending in "!". same holds true for "file:/jruby-stdlib-1.7.17-SNAPSHOT.jar!/META-INF/" but juby currently gets "translated" into "jar:file:/jruby-stdlib-1.7.17-SNAPSHOT.jar!/META-INF/". the latter is just not the same from java point of view but are treated the same from jruby point of view.

so I can not fix the underlying issue since any fix will break things here or there. maybe someone just decides what is wanted.

for the record - I missed to add my test.rb script:

$LOAD_PATH << 'jar:file:./my.jar!/'
require 'hello1'

$LOAD_PATH << 'jar:file:./my.jar!'
require 'hello2'