Groovy: A superset* of the Java language, you can (generally) rename a .java file to get a valid .groovy file. Groovy uses the Java libraries -- a Groovy string is a Java string. A Groovy object can subclass a Java object and vice versa.
Groovy is perfect for Java developers who want a gentle learning curve for new language features and want fine-grained interaction with other existing Java (and JVM) libraries and components.
JRuby: A full* implementation of JRuby and libraries that runs on the JVM. A Ruby string is not a Java string. JRuby can call Java and vice versa, but there's some impedance mismatch because of differences in the object libraries.
JRuby is great for Ruby developers and/or people who need to run Ruby-based technologies in the JVM environment (e.g. Rails, Asciidoctor, etc.)
Most people knowledgable of both technologies would not view this as (unnecessary) fragmentation. There has also been some work on the JVM that has benefitted both languages -- most notable the InvokeDynamic byte code additions to better support dynamic languages (benefiting Groovy, JRuby, JavaScript, and others.)
* There are some corner-cases where valid Java is not valid Groovy. Similarly, there are some C-language extensions in Ruby that aren't' available in JRuby. But in both cases the exceptions are rare enough to be relegated to a footnote.
Java 8 will make Groovy completely irrelevant: the lambdas will make Groovy closures redundant, and the bundled Nashorn Javascript will take away Groovy's use case for quick & dirty testing scripts.
...why do we have both a Ruby-like language and a Ruby implementation running atop the JVM? Sounds like a lot of fragmentation and wasted resources.