如何从一个源生成多个 Maven 工件

发布于 2024-11-01 18:58:13 字数 1175 浏览 1 评论 0原文

我知道这违反了 Maven 最佳实践,但也许我的情况是该规则的少数例外之一 - 至少我一直在思考替代方案:(

环境是这样的:

  • 我们有一个基于专有技术的遗留应用程序与外界的接口
  • 我们希望基于遗留接口使用 flash 作为新的前端
  • 我们生成 flash 类并将它们打包在 flash SWC 中,供前端开发人员
  • 基于遗留接口使用 我们生成桥接 flash 的 java 类服务请求(来自blazeds)到我们的遗留接口
  • 使其变得更加困难,我们不想/不能为每个接口单独使用一个pom,因为我们有几十个接口,它们只会在artifactId上有所不同。我使用一个“通用”项目结构,它将为每个构建进行参数化(由 jenkins 实现)。该项目将在完全自动化的环境中使用

。 “简单的”项目,该项目将一直运行到应安装工件的位置。

我当前的方法是受 maven 参考第 13 章启发的多模块项目结构,它本身有一些缺点:

GenericProject
|
+-- GenerateSources from legacy interface
|   +-- pom.xml
|
+-- Java 
|   +-- pom.xml
|
+-- SWC 
|   +-- pom.xml
|
+-- pom.xml

这种方法有一个缺点,我有来自“Java”和“Java”的参考资料。 “SWC”到“GenerateSource”的内部结构,丑陋但可以忍受。
真正阻碍我的是是我必须大力调整安装和安装。部署插件以获取具有名称和名称的工件;触发整个过程的遗留接口版本。 我现在可以运行它,但它看起来很脆弱。

我考虑将项目拆分/复制为两个简单的项目:

  • GenerateSources & Java
  • 生成源 & SWC

但这只能解决交叉引用的小麻烦。

正如亚伦在评论中指出的那样,我在陈述问题时不清楚。 经过更多的实验后,我变得更加清楚了: 本质上,我有两个问题需要解决

  1. ,将两个工件一起安装/部署,
  2. 这些工件的名称与 project.artifactId 不同

有什么建议可以让整个过程更像专家吗?

提前致谢。

I understand that this is against maven best practices, but maybe my situation is one of the few exceptions from the rule - at least I'm stuck with thinking of alternatives :(

The environment is this:

  • we have a legacy application with proprietary technology based interfaces to the outside world
  • we want to use flash as the new frontend
  • based on the legacy interface we generate flash classes and package them in a flash swc to be used by the frontend developers
  • based on the legacy interface we generate java classes which bridge the flash service requests (coming via blazeds) to our legacy interface
  • to make it more difficult, we don't want to / can't use a pom on it's own for each interface as we have dozens of them (interfaces) and they would only differ in their artifactId. Instead I use a "generic" project structure which will get parameterized (by jenkins) for each build. The project will only be used in an fully automated environment.

First I've tried to put all these in one "simple" project, which works up to the point where the artifacts should get installed.

My current approach is a multimodule project structure inspired by maven reference chapter 13, which has some disadvantages on it's own:

GenericProject
|
+-- GenerateSources from legacy interface
|   +-- pom.xml
|
+-- Java 
|   +-- pom.xml
|
+-- SWC 
|   +-- pom.xml
|
+-- pom.xml

This approach has the disadvantage, that I have references from "Java" & "SWC" to the internal structure of "GenerateSource" which is ugly but tolerable.
What really gets in my way is that I have to heavily tweak the install & the deploy plugins to get artifacts with the name & version of the legacy interface which triggered the whole process.
I got it running now, but it looks very brittle.

I considered splitting/duplicating the project in two simple projects:

  • GenerateSources & Java
  • GenerateSources & SWC

But this would only solve the minor annoyance with the cross-references.

As Aaron pointed out in his comment, I'm unclear in stating the problem.
After some more experiments this got a lot clearer to me:
Essentially I have two problems to solve

  1. install/deploy two artifacts together
  2. name the artifacts different than the project.artifactId

Any suggestions to make the whole process more maven-like?

Thanks in advance.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

浸婚纱 2024-11-08 18:58:13

在使用多模块方法走了一些弯路之后,我得出了以下实用的解决方案:

  1. 使用 build-helper-plugin 附加要自动安装/部署的辅助工件
  2. 两阶段构建:

    2.1 通过 sed 生成 pom.xml,其中包含已解析的 project.artifactId & 项目.版本

    2.2 运行maven构建

虽然理论上你可以使用表达式作为project.artifactId & project.version,maven 会为此向您发出警告。 。 。有充分的理由:
当您尝试引用生成的工件时,nexus 将为您提供“无法读取...的工件描述符”。错误。
我怀疑这是因为在存储库中存储的 pom 中表达式未解析!

After some detours with the multimodule approach I came to the following pragmatic solution:

  1. use the build-helper-plugin to attach a secondary artifact to be installed/deployed automaticly
  2. two-phase build:

    2.1 generate a pom.xml via sed which contains resolved project.artifactId & project.version

    2.2 run the maven build

Although you theoretically can use expressions as project.artifactId & project.version, maven gives you a warning for this . . . for a good reason:
When you try to reference the produced artifacts, nexus will give you a "Failed to read artifact descriptor for . . ." error.
I suspect this is because in the stored pom in the repository the expressions are unresolved!

花开柳相依 2024-11-08 18:58:13

您应该编写一个小的 Maven 插件,并将其附加到 generate-sources 阶段。有关示例,请参阅 maven-annotation-plugin (主类)。

这将在 GenerateSource 的输出中包含生成的源,您只需在其他 POM 中包含依赖项即可使用这些类。请注意,您应该在 target/ 下创建这些文件,而不是在 src/ 中。

至于安装/部署:这些插件的名称来自创建工件的插件。所以肯定是你设置属性的方式有问题。就您而言,这就是 JAR 插件。该文档有一个示例,如何设置默认工件

You should write a small Maven plugin that you attach to the generate-sources phase. See the maven-annotation-plugin for an example (main class).

That will include the generated sources in the output of the GenerateSource and you can consume those classes just by including the dependency in the other POMs. Note that you should create those files under target/, not in src/.

As for install/deploy: Those plugins get their names from the plugins which create artifacts. So there must be something wrong with how you set the property. In your case, that's the JAR plugin. The documentation has an example how to set the name of the default artifact.

时光礼记 2024-11-08 18:58:13

尝试使用 Maven 覆盖,它用于在多个 Web 应用程序之间共享资源。

http://maven.apache.org/plugins/maven-war-plugin /overlays.html

Try using Maven overlays, it's used to share resources between multiple web applications.

http://maven.apache.org/plugins/maven-war-plugin/overlays.html

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文