General questions on Maven

[Suhaas Parekh]

Hello All,

I have the following general questions on Maven:

1. What is the purpose of scope tag in the dependency section of pom.xml?
2. What is meant by classpaths with respect to maven?
3. Is a classpath in maven scopes similiar or related to the general term classpath which is the place the JDK has to look for user defined classes?
4. When exactly would I use a compile scope, which is also the default scope? Please explain with example.

[Tim Cooke]

The Maven Documentation is your friend here

1. https://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#dependency-scope
2. Don't understand the question but maybe to do with the directory layout https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html
3. Don't understand the question, perhaps an example might help?
4. Same as 1 https://maven.apache.org/guides/introduction/introduction-to-the-standard-directory-layout.html

[Suhaas Parekh]

What is runtime classpath and test classpath? Is there also a compile classpath? If yes, what is it?

[Suhaas Parekh]

What is meant when it is said that a dependency with certain scope will be available only during that scope? Is it not true that when a dependency is included it is needed at all times i.e compile time/run time etc?

Instead of using maven, if I manually download a dependency jar and put in the build path of a project in eclipse, with what scope is it included in the project?

[Tim Holloway]

There are 3 scopes that you may commonly encounter.

compile scope puts the artefact in the compilation classpath AND includes a copy of the artefact in the target artefact.

provided scope puts the artefact in the compilation classpath, but does NOT include a copy in the target artefact. You use this for libraries that are provided from an external source. For example, the JEE API implementation JARs are part of the webapp server, so you don't want them duplicated in the WAR you build with Maven (it can cause real problems, in fact).

test scope puts the artefact in the compilation and run classpaths for when Maven runs tests, but not in the target artefact. Because test artefacts are not useful as part of a production (non-test) product.

No. Don't manually download a JAR and include it separately. At best, you'll be able to build properly only with the IDE and one of the best reasons for Maven is to be able to build when you don't have an IDE. IDEs also break more easily. If you have a JAR that's not part of the standard Maven repository and not something you build using Maven, you can catalog it into your local Maven repository and treat it just like any other Maven artefact. I often do this with JDBC driver JARs, in fact.

Maven does expect you to have a particular directory structure for your projects, and initially that's one of the reasons I hated it. Years later, I've come to appreciate the fact that someone can hand me a foreign project and I'll know exactly where to look for things.

You really shouldn't be setting a classpath for Maven builds. Maven's own classes can be found via the MVN_HOME environment variable. Everything else is stuff that Maven itself should be putting into its working classpath.

[Rob Spoor]

Suhaas Parekh wrote:4. When exactly would I use a compile scope, which is also the default scope? Please explain with example.

The better question is, when would you not use compile scope? It's the default for a reason.

Here's my thoughts on when to use the other scopes:

Scope	When to use
provided	Like Tim said, when the dependency is provided by the platform or server. His JEE example is one of the most common cases.
runtime	This is the opposite of provided. Where provided dependencies can be used to compile against but are not part of your application, runtime dependencies are part of your application but you cannot use them to compile. So when do you use it? Almost never. The only example I can think of is database drivers; you use JDBC (or a layer on top of it like JPA) to compile against, not the driver itself. Note that you should only do this for self-contained applications, like Spring Boot. For JEE containers, the container should be configured with the data source, not the application itself.
test	Again, like Tim said, just for testing. The most common test dependencies are JUnit, Assert4J, Mockito, and other dependencies that just allow you to build your tests. Other test dependencies can be implementations of specifications. For instance, you have a provided dependency on the JPA specification, and a test dependency on an implementation like Hibernate.
system	When you have an external JAR file that cannot be downloaded as a different type of dependency. This is like provided (as in, it doesn't get automatically bundled in your application) but you have to link to the JAR file manually. You should only use this if you cannot upload the JAR file to a Maven repository like Nexus.
import	When you have a different POM and you want to include all of its dependencies. A good example is spring-boot-dependencies. If you have a dependencyManagement block, and in it add a dependency with type import, all of the Spring Boot dependencies can be used without having to specify the versions. That's because these come from the imported POM. I would (almost) never use this scope outside of dependencyManagement, because it will really import everything. If you add spring-boot-dependencies in the regular dependencies, your application will get everything that Spring Boot offers. That's a lot, and your application will be unnecessarily large.

[Tim Holloway]

Rob Spoor wrote:
...You should only use this if you cannot upload the JAR file to a Maven repository like Nexus.

And, as I said, it's still better if you catalog it in your own local repository. That's the first place Maven will look, followed by external (e.g., site) repositories such as Nexus, then finally in the official Maven repos.

[Stephan van Hulst]

Rob Spoor wrote:This is the opposite of provided. Where provided dependencies can be used to compile against but are not part of your application, runtime dependencies are part of your application but you cannot use them to compile. So when do you use it? Almost never. The only example I can think of is database drivers; you use JDBC (or a layer on top of it like JPA) to compile against, not the driver itself.

I don't agree with this assessment. I use runtime dependencies a LOT. They're commonly used for implementations of an API.

For example, you might specify that your application is compiled against the Jakarta JAX-RS API, but you still need an implementation at runtime for application containers such as Tomcat. You can specify an implementation such as GlassFish Jersey with the runtime scope.

[Rob Spoor]

That's a scenario I hadn't thought of. I write most of my code for JBoss/WildFly, Spring Boot or Quarkus, and in all cases the implementations are already provided for me. There's no need to bundle it with the application.