使用Maven打包JAR和WAR时的Spring引导迁移问题

我们正在尝试将现有的SpringMVC应用程序迁移到SpringBoot应用程序。我们现有的应用程序正在使用3.2.9，因此需要大量的XML配置。所有bean都在XML文件中定义。我们所做的是首先将现有的应用程序升级到Spring4.2.5版本，因为SpringBoot只适用于Spring4版本

我们的要求是从构建中同时拥有胖jar和WAR文件。我们的大多数现有客户更喜欢应用服务器部署，因此我们必须为他们创建WAR文件。此外，对于我们的内部测试和新部署，我们计划使用FAT JAR

我们如何在Maven文件中实现它们，我们可以单独提供如下内容。是否有任何maven插件可以在单个构建中生成这两个插件

<packaging>jar</packaging>

jar

或

战争

我们正在将工件发布到Nexus存储库中。因此，我们希望为JAR文件和WAR文件提供单独的存储库位置。我们可以使用单个

pom.xml

文件来实现吗

还有一个问题，我们有

WEB-INF

文件夹下的所有XML配置。当我们移动到Spring引导应用程序时，它必须位于

resources

文件夹下。我们怎样才能轻松地处理它们呢。当我们构建胖jar时，不会在

WEB-INF

下查看资源，因为它只会忽略

webapp

项目

我期待着一些指导来完成迁移。事实上，我们已经做了这些改变，它工作得很好，但我们对这场战争/JAR时代感到困惑

更新：

---

我还想问另一个问题，如果我们将现有的应用程序转换为spring boot，我们是否仍需要在WEB应用程序中维护WEB-INF文件夹，或者可以将所有内容移动到resources文件夹？。在构建WAR文件时，spring boot是否负责将资源移动到WEB-INF？如果将所有资源放在

resources

文件夹下，spring boot将如何创建WAR文件。

使用Gradle构建WAR和FAT JAR非常简单

对于Maven，我会尝试，其中一个子模块将构建fat JAR，第二个子模块将构建WAR文件

应用程序逻辑可以作为第三个子模块，因此是带有Spring配置和bean的独立JAR。这个应用程序逻辑JAR将作为fat JAR和WAR模块的依赖项。 特定于战争的配置可以放在Maven WAR子模块中

我以前没有这样的要求，所以不知道会发生什么挑战。当然，我不会尝试将

maven汇编插件

或其他打包插件与

springbootmaven插件

集成

---

关于配置文件的位置，只需根据Spring引导约定将它们放入

src/main/resources

或其子文件夹中即可。Spring Boot是一个固执己见的框架，如果您不抵制默认设置，它将对您最为友好。

Maven并没有优雅地处理这个问题，但它远不是很难解决。您可以使用3个pom文件来执行此操作。一个父pom包含大部分配置，每个父pom一个用于工作的打包部分。这也将巧妙地将两种不同装配模式的关注点分开

---

澄清一下——我不推荐在这里使用多模块配置，只推荐多个名称为war-pom.xml和fat-jar-pom.xml的pom，以及父pom.xml。

只需使用

war

不要尝试两者都做。

war

也是可执行的，就像

jar

一样，我们还需要维护WEB-INF文件夹吗？我们可以将所有内容移动到资源文件夹？我认为你应该将所有内容移动到资源文件夹。我在gradle在大型蓝筹股公司的大型复杂项目方面有很多专业经验，如果我站在你的立场上，我会像躲避瘟疫一样避免它——它在各个方面都很可怕，很可能会把你的整个项目搞砸。坚持maven——与gradle将带来的问题相比，这一个麻烦算不了什么。@EngineerDollery在看到你的评论之前，我对gradle有一个更好的看法：）与gradle一起工作真的很可怕吗？这很受欢迎，但大多数是时髦人士和没有经验的工程师，他们不知道“好”是什么样子。它被设计破坏了。Gradle是Ant的升级版，它解决了该工具的所有问题。另外，您还必须学习groovy——这是一种最不受欢迎的语言。虽然maven有它的问题——xml不应该由人编写——但至少它是基于配置的工具的惯例，而不是一个大型脚本系统。有些事情在gradle一开始似乎比较容易，比如你这里遇到的问题，但我从来没有见过有人用它在20个主要项目中产生任何好的效果。是的。我也有同样的想法。我最好创建多个POM文件。这与我建议的有什么不同？@luboskrnac:我不推荐多模块配置，只推荐多个POM。我不认为你应该有一个模块仅仅用于人工制品的创作。我认为您应该有一个war-pom.xml和一个fat-jar-pom.xml以及一个parent-pom.xml，所有这些都用于一个模块。我将在回答中添加这一点来澄清。好的，您还应该提到，如果它是单独的POM，那么它将被视为单独的项目，也应该单独进行版本控制，托管在单独的Git存储库中，部署在单独的构建中到工件存储库中。从我的观点来看，太多的麻烦是无缘无故的。这是事实，但只有当项目正在经历一个标准的CI/CD过程（它应该是这样的）——因为CI/CD通常被配置为运行单个构建并生成单个工件，并通过一个自动化测试框架推动它。不过，您的多模块解决方案也是如此，其hassl量也差不多

<packaging>war</packaging>