In Maven 1 , it is necessary to list each package required by the dependency. This is too much of a concern for users who use something like Hibernate, and it's inconvenient. Transitive dependencies are implemented in Maven 2 , so for the packages that Hibernate depends on, Maven2 will automatically download them, and developers only need to care about Hibernate. So it can be seen that listing every jar needed is a feature in maven1, and maven 2 considers automatic download an improvement .
This leads to a problem: Although Maven 2 downloads all the jars required for compilation, not all the jars required for compilation are also required for running after being packaged into a war package. Therefore, it is found that many jars are unnecessary, and the war package is relatively large. We can improve by:
Strategy one:
For those provided by the container (such as: servlet-api-2.3, etc.) and those required for testing (such as: junit-3.81, etc.), they can be removed directly in pom.xml.
A tag in maven's dependency is <scope>option</scope> , and its option has the following values:
compile , the default, applies to all stages and is released with the project.
provided , similar to compile, expects the JDK, container or consumer to provide this dependency. Such as servlet-api-2.3.jar.
runtime , used at runtime, such as a JDBC driver, for both run and test phases. Such as plexus-utils-1.1.jar
test is only used when testing, to compile and run test code. Not released with the project. Such as Junit-3.8.1.jar
system , like provided, needs to explicitly provide the jar containing the dependencies, Maven won't look it up in the Repository.
Such as:
<dependency>
<groupId>servletapi</groupId>
<artifactId>servlet-api</artifactId>
<version>2.4</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>3.8.1</version>
<scope>test</scope>
</dependency>
Strategy two:
For third-party jars, transitive dependencies are passed to the war package, but are not required for distribution.
Such as: webwork-2.2.3.jar is used in our project. We can find that there is more spring-web-1.2.jar in the lib under war after packaging, but our project does not need this jar.
The first way: borrow <scope>provided</scope>
Although the original meaning of provided is that provided by jdk or container, it is only used in compilation, but not in war, but we can also borrow it.
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>1.2</version>
<scope>provided</scope>
</dependency>
The second way: use exclusions ; ( the effect is the same as the first )
<dependency>
<groupId>opensymphony</groupId>
<artifactId>webwork</artifactId>
<version>2.2.3</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</exclusion>
</exclusions>
</dependency>
策略三：
对于我们公司内部开发的jar包,我们都加上<optional>true</optional>，这样可以使引用这些jar的项目不会产生传递依赖。
如:项目mycom-csa中使用了mycom-cas-client-1.0.3.jar,然而mycom-cas-client-1.0.3.jar 又使用了mycom-common-security-1.0.3.jar。所以我们在对mycom-csa打包时会把mycom-common-security-1.0.3.jar打进package中。我们当然可以参考“策略二”，但最好的方法是：可以通知开发mycom-cas-client-1.0.3.jar的同事在mycom-cas-client-1.0.3.jar的pom.xml中对dependency修改为:
<dependency>
<groupId>com.mycom</groupId>
<artifactId>mycom-common-security</artifactId>
<version>1.0.3-SNAPSHOT</version>
<optional>true</optional>
</dependency>
添加<optional>true</optional> ，这样我们再打包时mycom-csa中就不会出现mycom-common-security-1.0.3.jar了。