

That’s a pretty common structure where most of the code probably resides in the “core” module while different aspects like a web frontend in the web module might be relying on the core functionality. We can also see that both “web” and “cli” depend on the “core” module. We have a root project (usually called “parent”) and 3 child projects “core”, “cli” and “web”.

Take a look at the following simplified project structure: a maven multi module project Sooner or later someone will tell you “well duh, you need to install the dependencies to your local repo” and from that point of time on running the occasional mvn clean install is just daily business. Maven really isn’t all that intuitive when it comes to how inter-project dependencies are resolved. If you’ve ever had the pleasure of working with so called “multi module” projects you know the pain. So my advice would be if you don’t necessarily know why you would use clean, just don’t it’s gonna be fine in the most cases. Only for it to be created again immediately by the next lifecycle phase. What the clean goal is doing is to try to delete every target folder in every module of your project. Not every “.java” file maps clearly to a pre-known output file. One could argue that in the case of java or JVM based projects this would be a tough task anyway.

Or should I say it is rather “dumb” enough? Maven tends to build more than is necessary because unlike ye olde autotools it doesn’t factor in file timestamps of source and target items to reduce the workload. we need to clean, or do we?įirst things first: why do we prefix the command with clean? Well the target directory could hold outdated stuff right? Can you actually remember a case where this was relevant? Maven usually is smart enough to deal with whatever is left over in the target directory. But actually it is probably doing more than you are looking for. You see mvn clean install has been handed around for years as the goto command to “build the software”. If you’re not convinced please keep reading.
