Clever Geek Handbook

Understanding Maven's Better Position

I have struggled to figure out what use of scope Maven gives as mentioned here .

Why don't you always have a pivot time chart? Real life examples would really be appreciated.

+3


source to share


4 answers


Dependent scopes compile

are used only at compile time.

Areas test

- only during trials. Let's say you have tests with junit or easymock. You obviously don't want your last artifact to depend on them, but you would like to be able to simply depend on those libraries while your tests are running.



Those dependencies that are marked as provided

are expected to be in your classpath when you run the generated artifact. For example: you have a webapp and you have a dependency on a servlet library. Obviously, you shouldn't package it in your WAR file, as the webapp container already has it and there could be a conflict.

One of the reasons there are different areas for dependencies is that different parts of an assembly can depend on different dependencies. For example, if you are only compiling your code and not running any tests, then there is no point in pointing Maven to your test dependencies (unless they already exist in your local repository, of course). Another reason is that not all dependencies need to be put into your last artifact (be it a build or a WAR file), as some of the dependencies are only used during the build and test phases.

+3


source


compilation

Will copy these jar files into the prepared War file.

Ex: hibernate-core.jar is a must have in our prepared war.

provided, These jars will be counted only if the testing time and time is observed



Example: servlet.jar

will be provided by the deployed server, so there is no need to provide from our prepared War file.

test

These jars are only needed to run test classes.

Ex: Junit.jar is only needed to run Junit test classes, no need to deploy them.

+3


source


The application areas are well explained here: https://maven.apache.org/pom.html#Dependencies

As a reference, I copied the paragraph:

scope: this element refers to the classpath of the task (compilation and runtime, testing, etc.) and how to limit the transitivity of the dependency. There are five areas available:

compilation is the default scope that is used if none is specified. Compilation dependencies are available in all classes. In addition, these dependencies are propagated to dependent projects.

provided - this is similar to compilation, but indicates that you expect the JDK or container to provide it at runtime. It is only available for compilation and test classpath, and is not transitive.

runtime - This scope indicates that the dependency is not required for compilation, but for execution. It is in runtime and checks classpaths, but does not compile classpath.

test - This area indicates that the dependency is not required for normal application use and is only available for the compilation and test execution phases.

system - this area is similar to the one provided, except that you must provide a JAR that contains it explicitly. The artifact is always available, not viewed in the repository.

+2


source


there are several reasons why you don't want all dependencies to be compiled scope by default

  • reduce the size of the final artifact (jar, war ...) by specifying a different scope.
  • If you have a project with multiple modules, you have the option to let each module have its own version of the dependency
  • avoid clashing the class version with the provided scope , for example if you are going to deploy a war file to a weblogic server you need to get rid of some javax jars like javax.servlet, javax.xml.parsers, JPA etc, otherwise you may encounter a class collision error.
+1


source






More articles:


All Articles