通过定义统一的父 pom（parent pom），将企业内部常用的 10 个自定义依赖和插件集中声明，所有新测试项目只需继承该父 pom 即可自动获得全部依赖，彻底避免重复编辑 pom.xml。

在高频创建短期测试项目的场景下（如每日数十个轻量级验证工程），手动为每个 pom.xml 添加相同的一组内部依赖和插件不仅低效，还极易出错、难以维护。Maven 原生不支持“命令行动态注入依赖”（区别于 Gradle 的 -P 或 --include-build），也无法通过 maven-dependency-plugin 绕过声明式依赖管理——所有参与编译、测试、打包的依赖必须显式声明在有效的 POM 结构中。因此，真正符合 Maven 设计哲学且生产就绪的解法是：复用父 POM 机制。

✅ 推荐方案：构建企业级父 POM

1. 新建一个专用的 parent-pom 项目（如 company-bom-and-plugins），其 pom.xml 定义如下核心结构：

  4.0.0
  com.company
  company-parent-pom
  1.0.0-SNAPSHOT
  pom

  
  
    
    
  
        com.company
        internal-utils
        2.3.1
      
      
        com.company
        test-support-plugin
        1.5.0
      
      
    
  

  
  
    
      
        
          org.apache.maven.plugins
          maven-compiler-plugin
          3.11.0
          
            17
            17
          
        
        
          com.company
          internal-deploy-maven-plugin
          0.9.2
        
        
      
    
  

? 关键点：使用 可确保子项目按需声明依赖（仅写 groupId + artifactId，无需 version），而 则让插件配置全局生效，子项目 中引用即启用。

2. 发布父 POM 到公司私有仓库或本地仓库
   执行以下命令，将父 POM 安装至本地供开发快速验证：

   cd company-parent-pom
   mvn clean install

   若已接入 Nexus/Artifactory，建议配置 并运行 mvn deploy，使所有团队成员均可远程拉取。

3. 新测试项目继承该父 POM
   新建任意空项目，其 pom.xml 仅需最简结构：

   
   
   4.0.0
   
    com.company
    company-parent-pom
    1.0.0-SNAPSHOT
   
   test-project-alpha
   0.0.1-SNAPSHOT

✅ 此时运行 mvn compile 或 mvn help:effective-pom 即可验证：所有预设依赖与插件均已生效，且零配置侵入。

⚠️ 注意事项与进阶建议

• 不要滥用 直接声明：父 POM 中应优先使用 ，避免子项目被动引入不需要的依赖（如 scope=runtime 的库被强制 compile）。
• 版本更新策略：将父 POM 版本设为 SNAPSHOT 便于快速迭代；正式发布时建议使用语义化版本（如 1.0.0），并通过 CI 自动触发子项目兼容性检查。
• IDE 支持：IntelliJ 和 Eclipse 均能自动识别继承关系并索引父 POM 中的依赖，无需额外配置。
• 替代方案辨析：
  • 多模块项目：适用于强耦合、长期维护的组件集，但会增加项目根目录复杂度，不符合“短生命周期测试项目”场景；
  • Archetype（脚手架）：适合初始化阶段，但后续依赖变更仍需同步更新 archetype，维护成本高于中心化父 POM；
  • settings.xml profiles：无法注入 ，仅能控制仓库、镜像、属性等，不解决本题核心诉求。

综上，基于父 POM 的依赖与插件集中治理，是 Maven 生态中最标准、最稳定、最易落地的企业级实践。一次建设，长期受益——开发者只需关注业务逻辑，而非构建配置的重复劳动。