google-code-export / wro4j

Automatically exported from code.google.com/p/wro4j
1 stars 1 forks source link

upgrade to latest version of jruby #805

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
wro4j-maven-plugin:jshint 1.7.1 depends wro4j-extensions which depends on 
jruby-core 1.7.4 which depends on jnr-ffi 1.0.4 which depends on jffi 
1.2.8-SNAPSHOT which was recently removed from Maven Central so now the code no 
longer runs.

Upgrading to JRuby 1.7.5 fixes the problem.

Original issue reported on code.google.com by cow...@bbs.darktech.org on 20 Oct 2013 at 3:24

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 20 Oct 2013 at 7:34

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 20 Oct 2013 at 8:04

GoogleCodeExporter commented 9 years ago

Original comment by alex.obj...@gmail.com on 20 Oct 2013 at 8:11

GoogleCodeExporter commented 9 years ago
Reopening this issue, since upgrading to jruby-1.7.5 has the following problem:
"(LoadError) no such file to load -- rubygems"

I doubt that there is a snapshot transitive dependency on jruby, since maven 
central repo is quite strict regarding this rule and doesn't allow release 
artifacts having snapshot transitive dependencies.

Will fix this issue when a workaround for jruby upgrade is found.

Original comment by alex.obj...@gmail.com on 21 Oct 2013 at 8:51

GoogleCodeExporter commented 9 years ago
I couldn't find a bug report against JRuby 1.7.5 for "(LoadError) no such file 
to load -- rubygems". Are you sure your working environment isn't somehow 
corrupt?

Original comment by cow...@bbs.darktech.org on 21 Oct 2013 at 9:12

GoogleCodeExporter commented 9 years ago
The same error is reported by travisCI which builds the project on a
dedicated box. It could be a problem on linux only (I didn't test it on
windows), but that is enough to postpone the upgrade since it wouldn't be
cross platform anymore.

Original comment by alex.obj...@gmail.com on 21 Oct 2013 at 9:16

GoogleCodeExporter commented 9 years ago
In that case, I suggest reporting it to JRuby otherwise they won't fix it.

Original comment by cow...@bbs.darktech.org on 21 Oct 2013 at 9:18

GoogleCodeExporter commented 9 years ago
I have found a workaround on SO: 
http://stackoverflow.com/questions/10833732/jruby-no-such-file-to-load

But I didn't have time to properly test it. Could you help me?

Original comment by alex.obj...@gmail.com on 21 Oct 2013 at 9:21

GoogleCodeExporter commented 9 years ago
I'm about to step out for an appointment. I'll try to take a look at this 
sometime tomorrow.

Original comment by cow...@bbs.darktech.org on 21 Oct 2013 at 9:24

GoogleCodeExporter commented 9 years ago
Sure, don't worry. Anyway, I consider this task low priority, since I don't 
really understand what are the benefits of upgrading to latest version of 
jruby. Also,  clients can enforce whatever jruby version they need by 
configuring dependencyManagement section in maven.

Original comment by alex.obj...@gmail.com on 21 Oct 2013 at 9:27

GoogleCodeExporter commented 9 years ago
Alex,

How do I reproduce the problem you reported (no such file to load)? I never ran 
into this error on my end.

Original comment by cow...@bbs.darktech.org on 22 Oct 2013 at 10:05

GoogleCodeExporter commented 9 years ago
I nuked my local Maven repository and now I no longer get a dependency on jffi 
1.2.8-SNAPSHOT so I think it's safe to say that my environment was corrupt.

That being said, we'll eventually want to upgrade JRuby so I'm still interested 
in resolving this problem. Please let me know how to reproduce the error you 
saw and while you're at it, check whether your environment is corrupt as well 
since I didn't get that error on my end :)

Original comment by cow...@bbs.darktech.org on 23 Oct 2013 at 1:56

GoogleCodeExporter commented 9 years ago
I think this has something to do with ruby configuration on your local 
environment. To reproduce it easily, use a clean environment with nothing else 
installed. 
What OS are you using?
To reproduce it easily, checkout from github the branch "issue805" and build it 
on jenkins or TravisCI. I have pushed the changes recently, so you can see that 
the build fails because of the problem mentioned above.

Let me know if you have any suggestions.

Original comment by alex.obj...@gmail.com on 23 Oct 2013 at 7:14

GoogleCodeExporter commented 9 years ago
[deleted comment]
GoogleCodeExporter commented 9 years ago
Here is the console log from failed build on TravisCI where you can see the 
error:
https://travis-ci.org/alexo/wro4j/builds/12918737

Original comment by alex.obj...@gmail.com on 23 Oct 2013 at 9:18

GoogleCodeExporter commented 9 years ago
I can confirm this issue is specific to Linux. I can reproduce it under Ubuntu 
but not Windows.

Original comment by cow...@bbs.darktech.org on 30 Oct 2013 at 9:20

GoogleCodeExporter commented 9 years ago
The problem here is that JRuby can't find its standard library, and 1.9 mode 
loads rubygems from stdlib at boot. You can fix this in a few ways:

* Set an on-disk home dir for JRuby to use.
* Force JRuby into 1.8 mode with the --1.8 flag (or setting compat mode in the 
JRuby instance).
* Disable gems with the --1.8 flag (or setting appropriate flag in JRuby 
instance).

Original comment by head...@headius.com on 30 Oct 2013 at 10:44

GoogleCodeExporter commented 9 years ago
headius nailed it. It turns out that jruby-core 1.7.4 used to depend on 
jruby-stdlib but in 1.7.5+ it does not. wro4j depends on rubygems which means 
it need to add jruby-stdlib as an explicit dependency.

Original comment by cow...@bbs.darktech.org on 31 Oct 2013 at 12:32

GoogleCodeExporter commented 9 years ago
Posted pull request at https://github.com/alexo/wro4j/pull/158

Original comment by cow...@bbs.darktech.org on 31 Oct 2013 at 1:49

GoogleCodeExporter commented 9 years ago
@cowwoc Thanks for the contribution.

Fixed in branch 1.7.x.

Original comment by alex.obj...@gmail.com on 31 Oct 2013 at 8:23

GoogleCodeExporter commented 9 years ago
If you use jruby artifact that depends on both jruby-stdlib and jruby-core.  
Our transition to full maven build ended tweaking the artifacts a little bit...

Original comment by tom.en...@gmail.com on 31 Oct 2013 at 4:00

GoogleCodeExporter commented 9 years ago
@tom could you elaborate?

Original comment by alex.obj...@gmail.com on 31 Oct 2013 at 4:03

GoogleCodeExporter commented 9 years ago
Sorry we release many artifacts and one is called just 'jruby'.  This artifact 
has dependencies of jruby-core and jruby-stdlib.

Original comment by tom.en...@gmail.com on 31 Oct 2013 at 9:15