Maven war包相互依赖

本文介绍了解决Java项目中WAR文件依赖问题的方法。通过调整maven-war-plugin插件配置,可以实现在WAR文件中包含类文件的JAR,并在其他依赖项目中正确引用这些类。

假设有两个war包:A和B。A又依赖于B。根据Java规范,classpath不能指定WAR文件。这就意味着在编译时,A项目无法访问B项目中定义的类,所以在A项目中,我们不能像常规类组件那样扩展或使用B定义的类。要解决这一问题,我们必须重新设置maven-war-plugin的一项缺省配置,该设置如下面所示。

将以下配置添加到B项目的Maven pom.xml文件中。

<build>

  <plugins>

    <plugin>

      <artifactId>maven-war-plugin</artifactId>

      <configuration>

        <!-- 把class打包jar作为附件 -->
<attachClasses>true</attachClasses>
<!-- 将项目的类文件打成jar放到lib目录中
<archiveClasses>true</archiveClasses>
-->

      </configuration>

    </plugin>

  <plugins>

<build>

启用attachClasses选项可以把JAR文件(warsaw-1.0-classes.jar)和标准的WAR文件同时安装到Maven仓库中。要访问该JAR文件,我们需要如下所示的那样修改A项目的依赖列表。

<dependencies>  
  <dependency>    
  <groupId>com.example.modular</groupId>    
  <artifactId>B</artifactId>    
  <version>1.0</version>    
  <type>war</type>  
</dependency>  
<dependency>    
   <groupId>com.example.modular</groupId>    
   <artifactId>B</artifactId>    
   <version>1.0</version>    
   <type>jar</type>    
   <classifier>classes</classifier>    
   <scope>provided</scope>  
</dependency>
</dependencies>

A项目用B WAR创建最终的Web归档文件,出于编译需要,还使用了B的类(打包在JAR里)。我们将属性classifier设置为classes,以此定义该从仓库中选择哪个工件。将scope设置为provided,则是告诉Maven只在编译时需要该工件,运行时则从其他地方获得。“其他地方”就是指B项目的WAR工件,WAR插件会将WAR和JAR合并在一起。


转载于:https://my.oschina.net/u/2277929/blog/610682

### Maven插件与Maven依赖的区别和联系 #### 一、定义区分 Maven中的**依赖**是指项目运行所需的各种库文件,这些库通常是以JAR的形式存在。通过`<dependencies>`标签声明的依赖项会被下载到本地仓库并供项目使用[^1]。 而**插件**则是用于执行构建生命周期中的特定任务,比如编译源码、打项目或者部署成品等。它们由`<build><plugins>`部分配置,并且遵循不同的命名空间规则来指定其功能实现的位置[^2]。 #### 二、作用范围对比 - **依赖的作用**: 主要是支持应用程序本身的逻辑运作, 它们被含在最终产物 (如WAR 或 JAR 文件) 中以便于程序能够正常工作. - **插件的功能**: 更侧重于辅助完成软件开发生命周期内的各项操作, 如测试覆盖率统计、文档生成或是资源过滤等等. 这些动作并不直接影响应用的核心业务流程. 例如,在实际开发过程中,当开发者希望查看复杂的POM文件结构以及解决可能存在的传递性冲突时,可以借助IDEA上的"Maven Helper"插件来进行直观展示与管理. 另外值得注意的是,某些情况下为了使自定义Mojo(即Maven Old Goalt)能访问外部库所提供的API接口,则需要正确设置classpath从而让ClassLoader识别目标classes。此时就需要考虑如何合理安排plugin自身的dependency scope属性值为'compile',而非简单的'provided'[ ^3]. #### 三、相互影响机制探讨 尽管两者服务于不同目的,但在具体实践中却存在着千丝万缕的关系: 一方面,许多标准插件内部也会利用第三方框架作为支撑组件;另一方面,用户自行扩展的新type/goal往往也需要额外引用相应的libraries才能达成预期效果。因此,在编写个人专属工具类module的时候,务必清晰界定哪些属于必要组成部分(应列为direct dependency),又有哪些仅限临时借用性质(可标记成optional or test scoped item)。 ```xml <!-- Example of plugin configuration --> <build> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-compiler-plugin</artifactId> <version>3.8.1</version> <configuration> <source>1.8</source> <target>1.8</target> </configuration> </plugin> </plugins> </build> <!-- Example of project dependencies --> <dependencies> <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <version>4.12</version> <scope>test</scope> </dependency> </dependencies> ``` 上述代码片段展示了典型的plugin setup方式及其关联性的体现形式之一——即通过调整各自参数选项达到最佳适配状态的同时保持良好的兼容特性[^1]。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值