Maven is arguably the most used build automation tool in the Java ecosystem. With that great power and popularity, comes great…configuration options! One such option that can leave you scratching your head is dependency scopes. This blog post takes a quick look at maven scopes, what they are and when to choose which scope.
What are Maven Dependency Scopes?
Think of your maven project as a construction site. You need tools (dependencies) to get the job done. Maven dependency scopes help you answer this question: “When, exactly, do I need each specific tool?”
Classpath and Life Cycles
There are two core concepts you’ll need to understand before we take a look at the available scopes in maven. They are classpath and life cycles. A classpath is the list of locations your Java project looks in when looking for the code it needs, whether it’s your own code or dependencies. When it comes to life cycles, a maven project has two core stages that it goes through. These are:
Compile Time: Think of compile time as the transformation of your Java code (.java files) into a language the Java Virtual Machine (JVM) understands – bytecode (.class files). This is where your project’s external libraries are linked, and the compiler may optimize your code for efficiency.
Runtime: Runtime is when your application comes alive. The JVM executes the prepared bytecode. Your application now responds to user input, interacts with databases and can even have parts of its code recompiled by the JVM on the fly for better performance.
The Essential Scopes:
Now let’s break down the most common dependency scopes:
compile (default): The workhorses of your project. Needed for both writing your code and running the finished application. Think of these as your hammer and nails.
provided: For tools that your target environment will provide. For example, you’d mark Jakarta EE dependencies as provided in your project because the runtime, like Payara Server, will provide that dependency. It’s like borrowing your construction site’s power drill.
runtime: Needed to run your application, but not during the initial coding phase. Examples could include database drivers. These are like paintbrushes and finishing tools.
test: Your quality control toolkit. These are dependencies used exclusively for testing (like JUnit or mocking libraries). Imagine these as safety glasses and inspection equipment.
system: A rarer scope. Used for dependencies that are very specific to the machine you’re running on (like a native library). It’s like expecting your client to have their own specialised saw already on-site.
Why Do Scopes Matter?
Smaller Builds: Using scopes correctly keeps your final application package as lean as possible by excluding unneeded dependencies at deployment time. For example, your packaged Jakarta EE application will not contain the Jakarta EE platform classes, as those will be provided by the runtime, e.g. Payara Server.
Clarity: Scopes make your project’s requirements clearer for both you and other developers that read your code.
Easier Maintenance: Precisely defined dependencies reduce the risk of version conflicts or missing pieces during deployment.
In the Real World (An Example)
Let’s say you’re building a web application. You’ll likely need:
compile: Core libraries and utilities without which the application will not compile.
provided: Your chosen web server’s provided libraries (if deploying to managed runtimes like Payara Server etc.)
Remember to take the time to consider the right scope for each dependency. This initial investment might seem small, but it pays significant dividends down the line. By carefully managing your project’s toolbox, you’ll create applications that are leaner, easier to understand and more resilient to the challenges of updates and unexpected environments. Think of it as the difference between a haphazard pile of tools and a well-organized workbench – the right organization makes every task smoother and more efficient.
5 minutes
