I think you're totally right. Reusing modules is much better than code duplication for obvious reasons.
However I would like to emphasize that there is a compilation classpath and a runtime classpath. I'll explain.
Build
In Maven there is a packaging property. It determines what type of artifact will be compiled out of the module. Usually (and by default) it's a jar.
So bottom line when you build you'll get a jar of Parser and will add it as a dependency to other module's pom.xml files.
Now this only means that during the compilation the parser binaries will be in the classpath (in other word if you have module A that depends on module Parser, inside the source of module A you'll be able to use class MyParser defined in module Parser).
That's how you build.
Runtime
Once the jar is ready you can't run it just as a stand-alone application. Maven doesn't handle it out of the box.
Runtime classpath is an entirely different thing.
So you'll have to decide how to actually run the application.
Here there are many possible options here:
Re-packaging all the binaries into one big fat jar (uber jar). Maven shade plugin can help here
Creating a custom layout and scripts for running the application. In this case take a look at maven-assembly-plugin
For web applications, just create a WAR module (one per application, war stands for "web archive") and pack everything into web-inf/lib inside the war. Maven does that automatically if you specify packaging "war". However in this case you'll need a container to run the war (Tomcat, Jetty and so forth).
Again, if it should be a web application, consider using more "fancy" stuff like Spring Boot. This will create a big fat jar with everything you need inside it, so you won't need to think about classpath at all.
I've missed a couple of methods here and there for sure, the choice is yours.