在非JAR maven项目之间共享公共资源

在非JAR maven项目之间共享公共资源,maven,maven-3,jmeter,Maven,Maven 3,Jmeter,我有几个Maven项目,比如说a,b,c,继承自一个单一的父项目(我们称之为parent),同时也是模块(与parent不同的项目,我们称之为super) 这些项目都有一个pom包装。每个项目都有特定的配置,但它们也有一个公共部分。更具体地说,每个项目都有两个JMeter测试配置文件:一个专用于给定项目,另一个通用于所有项目 问题是-我应该如何配置POM,以便在项目之间共享此公共配置文件? 一种解决方法是将它们合并到super,并使用概要文件。但是,在这种情况下,我必须手动为每个配置进行单独的构

我有几个Maven项目,比如说
a
b
c
,继承自一个单一的父项目(我们称之为
parent
),同时也是模块(与
parent
不同的项目,我们称之为
super

这些项目都有一个
pom
包装。每个项目都有特定的配置,但它们也有一个公共部分。更具体地说,每个项目都有两个JMeter测试配置文件:一个专用于给定项目,另一个通用于所有项目

问题是-我应该如何配置POM,以便在项目之间共享此公共配置文件?

一种解决方法是将它们合并到
super
,并使用概要文件。但是,在这种情况下,我必须手动为每个配置进行单独的构建(而现在我只能构建
super

也有类似的问题,比如,但是它们处理的是
jar
插件,这与本例无关

结构,供参考:

  • POM继承:

        parent
          |
    -------------
    |     |     |
    a     b     c
    
  • 文件结构:

    super
    |
    |-a
    |
    |-b
    |
    |-c
    
我也曾出于类似目的使用过。创建一个jar类型的单独资源项目(com.company:resourceProj)。将JMeter资源文件放入
/src/main/resources

/src/main/resources/common.properties  (your filenames obviously)
/src/main/resources/a.properties
etc.
按照中的说明创建捆绑包

现在,将此配置添加到父POM中(如果需要,请在测试配置文件中):


import
scope dependencies的思想是,您可以将共享资源放入一个单独的项目中,然后由许多其他项目导入;我想你可以用这种方式包含你的共享配置文件

您使用packaging
pom
(可能与父项目处于同一级别?)创建一个新项目,然后将其包含在父项目的
dependencyManagement
部分的scope
import
中。然后,您的每个子项目都可以通过继承来接收它。只需一个文件就可以完成整个项目,这似乎有些过分,但我不会有任何问题

实际上,我还没有在
pom
-打包项目树中尝试过这一点,因此您可能需要进行一些尝试,但我认为这种方法是合理的。这里有一个(非常广泛的)例子:


当您说“test config”是插件配置,还是JMeter的单独配置文件?作为保护继承的替代方案,您可以在中创建另一个配置项目,并在父项目中将其用作范围为“import”的依赖项@user944849:后者,我现在编辑了这个问题,使它更清楚。@柯南:你能把它作为一个答案发表并详细说明吗?另外,我不确定这是否会影响您的答案,但我可能应该指出,我正在使用
父项目继承一些Maven配置,例如插件和属性。这基本上迫使您使用
jar
工件类型,对吗?jar是共享资源项目的类型(您创建的单独项目)因为这就是
远程资源
插件构建的内容。使用共享资源项目的模块可能有您想要的任何类型。我以前曾使用此模式为类型为
pom
的项目包含共享资源。建议尝试一下,在cmd行上使用不同的阶段使用-X运行mvn,然后看一看您是对的,这并不是什么大问题,因为只有“资源”项目必须是
jar
。我将再试一次。我尝试采用此解决方案,但出现错误:未能执行目标org.apache.maven。插件:maven远程资源插件:1.5:process(加载资源)在项目父级上:找不到资源存档。这看起来是正确的,因为maven试图首先构建父级pom,即共享资源项目需要位于当前父级的旁边,而不是位于当前父级的下面,才能在父级之前进行构建,对吗?我在回答中添加了更多内容,以说明我以前是如何解决@jan的问题的。无需道歉:). 但是,我不确定导入范围是否允许引用项目中的文件,您链接的页面表明它仅用于依赖关系管理,引用:“项目可以从其他项目导入托管依赖关系。这是通过将pom工件声明为范围为“导入”的依赖关系来实现的。”,是的,你说得对。我猜您必须将共享资源打包到一个新的工件中,在这种情况下,您也可以依赖它。在过去,我发现在一个单独的库中共享测试代码是非常好的,我认为没有理由不能以相同的方式打包共享配置。没错,我认为创建一个单独的项目没有问题(这是我通常对公共代码所做的事),然而,这里的需求是能够在非
jar
项目中重用常见的非代码资源。是的,如果没有访问方便的Java类路径,那么将这些资源打包到jar或类似的容器中并没有多大好处,因为您以后必须解压jar才能读取它们。您可以直接使用
mvn安装:安装文件-Dfile=-DartifactId=shared.JMeter.properties-DgroupId=-Dversion=1.0-dpackage=properties将共享JMeter配置文件安装到Maven,然后将其作为依赖项添加。对于一个文件来说,这是可以的,但如果您有多个共享文件,则没有帮助,因此这不是一个完整的解决方案。值得一试吗?
<properties>
  <shared.resources.dir>${project.build.directory}/shared-resources</shared.resources.dir>
</properties>

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-remote-resources-plugin</artifactId>
  <executions>
    <execution>
      <id>load-resources</id>
      <phase>initialize</phase>
      <goals>
        <goal>process</goal>
      </goals>
      <configuration>
        <resourceBundles>
          <resourceBundle>com.company:resourceProj:version</resourceBundle>
        </resourceBundles>
        <attached>false</attached>
        <outputDirectory>${shared.resources.dir}</outputDirectory>
      </configuration>
    </execution>
  </executions>
</plugin>
<testResources>
    <testResource>
      <directory>${shared.resources.dir}</directory>
      <includes>
         <include>common.properties</include>
         <include>${module.file}.properties</include>
      </includes>
    </testResource>
    <!-- any other test resources here -->
  </testResources>
<properties>
  <module.file>a</module.file>
</properties>
<profile>
    <id>pom-packaging</id>
    <activation>
        <file>
            <exists>pom-packaging.marker</exists>
        </file>
    </activation>

    <build>
        <plugins>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-remote-resources-plugin</artifactId>
                <executions>
                    <execution>
                            <id>load-resources</id>
                            <phase>none</phase>    <!-- disables this execution -->
                        </execution>
                    </executions>
                </plugin>
          ....  other plugin executions here ....
         </plugins>
    </build>
</profile>