This can cause problems, apparently, on Mac OS X such as:
> Could not normalize path for file '/Users/asavchenko/.gradle/caches/modules-
NOTE: This has not yet been tested on OS X
According to @ysb33r:
Gradle 2.2 is indeed the culprit. There was binary change in the Jar class when
they moved it from a Groovy implementation to a Java one. It was corrected in a
subequent release, but 2.2 remains an issue.
Gradle 2.2 was just a bad release :(
Fixes#26
This contains some workarounds until jruby-gradle/redstorm#11 is fixed which
will allow us to work on JRuby 9k, until then we'll default to the latest
stable JRuby 1.7.x branch
Fixes#23
This goes hand-in-hand with jruby-gradle/redstorm#12 and allows us to
incorporate things like storm-kafka early on in the load time of a topology
while still allowing most JRuby-originating jar dependencies to be packed "as
per usual." (See fast-rsa-engine and others which pack jar files inside gem
archives)
Fixes#25
There's an issue with overriding copy() in Gradle 2.0 -> Gradle 2.2
<https://issues.gradle.org/browse/GRADLE-3207>
Caused by: groovy.lang.MissingMethodException: No signature of method: com.github.jrubygradle.storm.internal.JRubyStormJar_Decorated.copy() is applicable for argument types: () values: []
Possible solutions: copy(), any(), any(groovy.lang.Closure), notify(), wait(), find()
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.unwrap(ScriptBytecodeAdapter.java:55)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuperN(ScriptBytecodeAdapter.java:130)
at org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnSuper0(ScriptBytecodeAdapter.java:148)
at com.github.jrubygradle.storm.internal.JRubyStormJar.copy(JRubyStormJar.groovy:43)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:63)
The BC version being included was an artifact from using older versions of
jruby-complete (pre 1.7.20), see 5d59833e998ceed24e0805e09d36897de770838f
The fact that this doesn't fail any tests is a problem :)
0.9.2 includes many fixes/improvements and is API incompatible with 0.9.1. The
only requirement that we have for 0.9.1 anymore is on storm topology
deployment, everywhere else we should rely on 0.9.2 if possible
This resolves some frustrating issues with incompatibilities with zookeeper and
curator dependencies underneath storm-kafka 0.9.2-incubating. If you've seen
"cannot initialize class `backtype.storm.LocalCluster` then that means that ZK
dependencies are somehow incorrect in the classpath causing the LocalCluster
class, which is defined in Clojure, to fail to get created. Cute error
R. Tyler Croy