相关疑难解决方法(0)

使用Maven开发OSGi应用程序时有两种主要方法:POM-first和MANIFEST first.

我正在寻找一个表格形式的答案,显示每种方法的优缺点.

更具体地说,我也想知道它与以下内容的关系:

• 工具集的成熟度
• 供应商独立性
• 开发方便(包括找到可以在工具上进行开发的人员)
• 兼容性
• 避免ClassNotFound
• 避免手工操作

我有一个多模块Maven项目,其中一些模块必须构建为Docker镜像.我试图将所有配置放在父POM中,如下所示:

父POM:

<build>
  <pluginManagement>
    <plugins>
      <plugin>
        <groupId>com.spotify</groupId>
        <artifactId>docker-maven-plugin</artifactId>
        <version>0.3.5</version>
        <configuration>
          <baseImage>java</baseImage>
          <imageName>${project.artifactId}</imageName>
          <entryPoint>["java", "-jar", "/${project.build.finalName}.jar"]</entryPoint>
          <resources>
            <resource>
              <targetPath>/</targetPath>
              <directory>${project.build.directory}/${project.build.finalName}-executable</directory>
              <include>${project.build.finalName}.jar</include>
              <include>lib/*.jar</include>
            </resource>
          </resources>
        </configuration>
      </plugin>
    </plugins>
  </pluginManagement>
</build>

儿童POM:

<build>
  <plugins>
    <plugin>
      <groupId>com.spotify</groupId>
      <artifactId>docker-maven-plugin</artifactId>
    </plugin>
  </plugins>
</build>

但是,当我运行mvn docker:build子项目时,我收到一个错误,因为该project.build.directory属性已解析为父POM的目标目录,而不是子目标目录.

是否有可能延迟父POM中属性的扩展？或者project.*从父POM 引用子项的属性？

想象一下，我们使用Gitflow，从中分离出一个发布分支develop，最终将合并到 和main中develop。只有release质量的改进。其中大多数需要部署到集成阶段，因此它们的版本有多个pom.xml（多模块），并且package.json在分支上更新和标记release。

上面develop有针对未来版本的常规（不稳定）功能开发，并且版本已相应设置。有时，来自 的改进release会合并回develop. 我们会遇到合并冲突，在下图中用 X 标记。

main     ----------------------o----
                              /
release        o---o-----o-o-o
              /     \     \   \
develop  ----o---o---x--o--x-o-x----
                           ^
               we are here |

例子：

• 上的release版本号是1.0.0-SNAPSHOT。
• 上的develop版本号是1.1.0-SNAPSHOT分支之后的。
• 新功能进入develop，版本号保持不变。
• 中的版本release偶尔会增加（并标记）为1.0.1、1.0.2等1.0.3。
• 现在，当我想将版本 1.0.x 合并到 1.1.0 而共同祖先是 1.0.0 时， 当然会发生冲突。
  • （我们完全理解那里发生的事情，不需要解释。）

$ git …