通过定义统一的父 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 定义如下核心结构：

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.company</groupId>
  <artifactId>company-parent-pom</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <packaging>pom</packaging>

  <!-- 统一管理所有内部依赖版本（BOM 风格） -->
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>com.company</groupId>
        <artifactId>internal-utils</artifactId>
        <version>2.3.1</version>
      </dependency>
      <dependency>
        <groupId>com.company</groupId>
        <artifactId>test-support-plugin</artifactId>
        <version>1.5.0</version>
      </dependency>
      <!-- 其余 8 个内部依赖... -->
    </dependencies>
  </dependencyManagement>

  <!-- 预置常用插件（含配置），子项目可直接使用 -->
  <build>
    <pluginManagement>
      <plugins>
        <plugin>
          <groupId>org.apache.maven.plugins</groupId>
          <artifactId>maven-compiler-plugin</artifactId>
          <version>3.11.0</version>
          <configuration>
            <source>17</source>
            <target>17</target>
          </configuration>
        </plugin>
        <plugin>
          <groupId>com.company</groupId>
          <artifactId>internal-deploy-maven-plugin</artifactId>
          <version>0.9.2</version>
        </plugin>
        <!-- 其他内部插件... -->
      </plugins>
    </pluginManagement>
  </build>
</project>

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

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

   cd company-parent-pom
   mvn clean install

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

   

   Apache Superset Dashboard and SQL Exploration Skill

   Apache Superset 是一个广泛采用的开源 BI 平台，用于 SQL 探索、图表构建和仪表板交付。当代理需要查询仓库数据、组装仪表板或使用成熟的分析界面解释指标而不是临时笔记本代码时，此技能非常有用。

   下载

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

   <?xml version="1.0" encoding="UTF-8"?>
   <project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
   <modelVersion>4.0.0</modelVersion>
   <parent>
    <groupId>com.company</groupId>
    <artifactId>company-parent-pom</artifactId>
    <version>1.0.0-SNAPSHOT</version>
   </parent>
   <artifactId>test-project-alpha</artifactId>
   <version>0.0.1-SNAPSHOT</version>

com.companyinternal-utilsjunitjunittest ```

✅ 此时运行 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 生态中最标准、最稳定、最易落地的企业级实践。一次建设，长期受益——开发者只需关注业务逻辑，而非构建配置的重复劳动。