I suppose you're talking about the "course-management" bit. That's just the way they named things. You could just as well have the following:

  <dependency>
    <groupId>net.java.dev</groupId>
    <artifactId>jvyaml</artifactId>
    <version>0.2.1</version>
  </dependency>

The artifactId is the name of the jar file.

Since you don't know about the ecosystem...there is no redundancy in his examples.

One could argue the conventions are poor though. groupId isn't really necessary. Most artifactIds are unique, and Maven Central could be the authority for (rare) naming conflicts. Works fine for ruby gems, apt repos, etc.

"com.google.guava:guava:18.0" could have been "guava:18.0".

Not really. You should have seen the discussion about the new Rust package manager. Putting everything top level means that good package names are taken forever by what is possibly abandonware. With namespacing everything is equal, first comers don't take over everything. Especially with the Maven/Java "use your reversed domain name" as groupId/package. Maybe it's a bit too verbose, but I'd still keep a group layer above the actual package name.

With namespacing, the namespaces end up being taken forever. A top level name of 'google/guava' isn't a big difference compared to namespace:google, artifact:guava.

If everyone followed the reversed-domain-name naming scheme, then namespaces taken up by abandonwares will get flushed out of the system after a few years.

That's a pretty huge "if" though.