-2

I've just started working on a project that has a lot of similarities in the code base between different programs. For example, four of the programs are parsing HTML pages, and each one has a util package with a Parser class (all of which are the same). My thought was to combine all these independent programs, in a structure like this:

- util (util related classes)
    - src
    - pom.xml
- net (network related classes)
    - src
    - pom.xml
- app1
    - src
    - pom.xml
- app2
    - src
    - pom.xml
- app3
    - src
    - pom.xml
- pom.xml

Then, when I need to use Redis in any of the apps, I just import net.Reis package (or import util.Parser to use the HTML parser). However, I'm quite new to things, and even after reading the multi-module guide here, I am still unsure if this is an appropriate model for completely different (but in many ways related) programs.

2 Answers2

1

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.

halfer
  • 19,824
  • 17
  • 99
  • 186
Mark Bramnik
  • 39,963
  • 4
  • 57
  • 97
0

Maven multi module project is not correct solution for this scenario.

The basic idea of breaking down the functionality into separate projects is correct. But in order to achieve that it is not neccessary to organize the projects into multi module maven project. Separate independent maven projects will do nicely.

Multi module maven project would be relevant if all those projects were to share the same life cycle, i.e. were released and versioned all the same. So the question is, when the app3 is going to be released, is the app1 going to be relased as well? If the version of app2 changes, shall the version of net project change as well? Only if the answer is yes, then the projects shall be organized as maven multi module project.

Michal
  • 2,353
  • 1
  • 15
  • 18