bin/{rake,rdoc,ri} broken by default in jruby 1.7.9 #1349

Closed
jeremyevans opened this Issue Dec 18, 2013 · 14 comments

Projects

None yet

4 participants

@jeremyevans
Contributor

It looks like jruby-1.7.9 stopped shipping the rake gemspec in between 1.7.6 and 1.7.9:

$ tar ztf /usr/ports/distfiles/jruby-bin-1.7.6.tar.gz | fgrep gemspec
jruby-1.7.6/lib/ruby/2.0/test/unit/test-unit.gemspec
jruby-1.7.6/lib/ruby/gems/shared/specifications/rake-10.1.0.gemspec
$ tar ztf /usr/ports/distfiles/jruby-bin-1.7.9.tar.gz | fgrep gemspec
jruby-1.7.9/lib/ruby/2.0/test/unit/test-unit.gemspec

This leads to the following situation:

c:\jruby-1.7.9>bin\jruby.exe -vS rake --version
jruby 1.7.9 (1.9.3p392) 2013-12-06 87b108a on Java HotSpot(TM) 64-Bit Server VM 1.7.0_07-b10 [Windows 7-amd64]
Gem::LoadError: Could not find 'rake' (>= 0) among 1 total gem(s)
  to_specs at c:/jruby-1.7.9/lib/ruby/shared/rubygems/dependency.rb:298
   to_spec at c:/jruby-1.7.9/lib/ruby/shared/rubygems/dependency.rb:309
       gem at c:/jruby-1.7.9/lib/ruby/shared/rubygems/core_ext/kernel_gem.rb:47
    (root) at c:/jruby-1.7.9/bin/rake:22

The same is true for rdoc and ri, except that they were broken even in 1.7.6 (note how their gemspecs aren't present in either tarball above).

It's fairly trivial to determine the reason. All three files use the standard rubygems shim, which does:

gem 'rake', version
load Gem.bin_path('rake', 'rake', version)

If you don't ship the gemspec, the gem call raises an exception.

I've tested this both on Windows using the exe+jre and OpenBSD using the bin tarball. As a work around, you can copy the real executable over the shim, or just install the gems separately. However, the correct fix is to ship the gemspecs for all binaries that use rubygems shims.

Note that this doesn't just effect binary usage, any code that calls gem 'rake' or something similar will break as well.

@mkristian
Member

it is a bit embarrassing that this is broken again :(
I will look to it and see if there is a way to add some tests for this

@mkristian
Member

so the situation is that the jruby/test/pom.xml does not do much (if any useful things at all) unless mvn -Pbootstrap is called.

but clean git clone and creating the release files or only the jruby-dist files will NOT execute the bootstrap stuff, i.e. there are no gems installed !

a little shuffling with bootstrap and jruby/test/pom.xml should fix this.

@headius
Member
headius commented Dec 19, 2013

I'm starting to think we should give up on using maven to build our release dist. A rake task would be more reliable than trying to hack profiles to do the right thing.

@mkristian
Member

the issue is not only the dist file but also the jruby-stdlib, jruby-jars
gem

I have (not pushed) yet but I do have tests now which verify the content:
the packed gems, that rubygems also finds them, that there are no futher
gems installed. that we have the respective bin files in place and that
they at least execute and show their versions.

the issue here is more that basically the same tests are in maven/jruby
maven/jruby-stdlib and maven/jruby-dist

so there are some duplications regarding the list of gems and their
versions. in order to get that into a common file it would be much easier
to use ruby-maven (tesla polyglot maven to generate the pom.xml files)
since then we could use ruby scripting inside the pom.rb to achieve this.

anyways the rake tasks can be buggy as well and the question is how to test
it.

AND it would be great if all those profiles:
jruby-jars
jruby-artifact
jruby-dist
would be executed on CI to ensure those new tests pass !

@mkristian
Member

ah - forgot jruby-complete which is also broken !! just add it to the list ;)

@headius
Member
headius commented Dec 19, 2013

I see no reason we couldn't run additional profiles and dist verification in CI. Just tell me what the commands should be :-)

@mkristian
Member
mvn -Pdist clean install
mvn -Pcomplete clean install
mvn -Pmain clean install
mvn -Pjruby-jars clean install
mvn -Pgems clean install
mvn -Pall clean install

it would be sufficient to run them on one CI run one after the other. probably the first is already covered somewhere else. thanx

@headius
Member
headius commented Dec 19, 2013

I'll incorporate them into the "extended" test. Trying it out here now.

@headius
Member
headius commented Dec 19, 2013

I pushed a new test:dist target to jruby-1_7 and master and enabled it in Travis, but it did not pass locally so I set it to allow failures. We'll see how it looks.

Is this bug now resolved?

@mkristian
Member

no I will push it later today some tests are still missing.

@mkristian
Member

so I pushed some fixes. let's see what travis says to it

when I wanted reuse the jruby-stdlib.jar to assemble the jruby-dist - to avoid repeated include pattern. there I realized that the jruby-stdlib.jar has three complete gems installed: rdoc, rake and json

needs to be fixed first.

@headius
Member
headius commented Dec 20, 2013

@mkristian: I merged some fixes of mine from jruby-1_7 to master, and made my merge it ignore your maven changes because I wasn't sure about status. You'll need to do that merge to master manually or make the same changes there.

@mkristian
Member

no problem - I cherry-pick what I need once jruby-1_7 is done and get
master up todate. got distracted today . . .

@mkristian
Member

merged to masters and fixed rdoc version to be 4.1.0.preview.1 everywhere on master

travis seems to stop if log output reaches 10000 lines :(
will look into this the next days but close ticket.

@mkristian mkristian closed this Dec 23, 2013
@enebo enebo modified the milestone: JRuby 1.7.10, JRuby 1.7.11 Feb 24, 2014
@byteit101 byteit101 added a commit to wpilibsuite/sfx that referenced this issue Dec 4, 2016
@byteit101 byteit101 Failing on errors and downgrading jruby as 1.7.9 was built incorrectly
Java and rake now report each others errors so jenkins will actually
report errors better now.
The JRuby complete jar for 1.7.9 is missing rake for some reason, so
downgrading to 1.7.8. Issue spotted in jruby/jruby#1349
173bcea
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment