java Maven 配置文件或弹簧配置文件？

maven profiles or spring profiles?

提问by Kent

a lot java applications are build with maven. maven has Profiles concept, it is really handy to build release package for different environments. e.g. dev/test/produsing different path / jndiname / security rule / properties files... I think I don't have to list codes here to explain it.

很多 java 应用程序都是用 maven 构建的。maven 有 Profiles 的概念，为不同的环境构建发布包真的很方便。例如dev/test/prod使用不同的path / jndiname / security rule / properties files......我想我不必在这里列出代码来解释它。

Spring is a very nice and popular framework for java development, since spring3 it has supported profiles concept too.

Spring 是一个非常好的和流行的 Java 开发框架，因为 spring3 它也支持配置文件概念。

Now question comes, for releasing to different ENVs purpose, which one is better? right now I prefer maven profile. since spring has to copy each bean definition in each profile. and it needs an initializer/property to let spring know which profile should be actived.

现在问题来了，对于发布到不同的 ENV 目的，哪个更好？现在我更喜欢 Maven 配置文件。因为 spring 必须复制每个配置文件中的每个 bean 定义。并且它需要一个初始化程序/属性来让 spring 知道应该激活哪个配置文件。

but I feel spring profile is more flexible than maven profile.

但我觉得 spring 配置文件比 maven 配置文件更灵活。

what do you think? please give some advices. thank you.

你怎么看？请给一些建议。谢谢。

回答by Filipe Fedalto

Maven profiles would provide a build-time solution, while SpringFramework profiles would provide a runtime alternative. I think this is the first question one may ask himself: if he wants to have a single package that can be deployed in different environments, or if he wants the build tool to provide different packages according to the destination environment.

Maven 配置文件将提供构建时解决方案，而 SpringFramework 配置文件将提供运行时替代方案。我想这是一个人可能会问自己的第一个问题：他是否希望有一个可以部署在不同环境中的单一包，或者他是否希望构建工具根据目标环境提供不同的包。

One thing to keep in mind is that many questions may arise if you have different packages deployed into different servers. In my workplace, for example, if I am deploying a package to correct a bug previously occurred in production environment, a company policy would state that the only acceptable scenario is that I have the same solution package in QA and in production servers.

要记住的一件事是，如果您将不同的包部署到不同的服务器中，可能会出现许多问题。例如，在我的工作场所，如果我正在部署一个包来纠正以前在生产环境中出现的错误，公司政策会规定唯一可接受的场景是我在 QA 和生产服务器中拥有相同的解决方案包。

回答by Ralph

If you need different artifacts then go with maven. If it is just a real configuration that can be configured AFTER the artefact is build then user Spring profiles.

如果您需要不同的工件，请使用 maven。如果它只是一个可以在构建工件后配置的真实配置，那么用户 Spring 配置文件。

回答by wemu

As mentioned in the other replies: it all depends on how you work :)

正如其他回复中所述：这完全取决于您的工作方式:)

What we came up with in the last years using maven and now the spring 3.1 profiles is this:

我们在过去几年中使用 maven 和现在的 spring 3.1 配置文件是这样的：

• we use the maven-release-plugin to cut releases. this causes issues with environments if we would use maven profiles since we would need to rebuild the release or at least the tag with every maven profile
• so we create on .war file for all environments and use the spring PropertyPlaceholderConfigurerto setup the application (or some JNDI resource depending on the customer). This allows to have only one maven release run.
• the spring profiles come in when environments differ as well. for example an authentication service that is not available on all environments. Here we stub that service and put it into a spring profile. We active the spring profiles in the properties that is read by the PropertyPlaceholderConfigurerwe use anyway.

• 我们使用 maven-release-plugin 来减少发布。如果我们使用 maven 配置文件，这会导致环境问题，因为我们需要重建发布或至少每个 maven 配置文件的标签
• 所以我们为所有环境创建 .war 文件并使用 springPropertyPlaceholderConfigurer来设置应用程序（或一些 JNDI 资源，取决于客户）。这允许只有一个 Maven 发布运行。
• 当环境也不同时，弹簧轮廓就会出现。例如，并非在所有环境中都可用的身份验证服务。在这里，我们存根该服务并将其放入弹簧配置文件中。我们激活了PropertyPlaceholderConfigurer我们使用的属性中的弹簧配置文件。

there are some nice tutorials around on how to do that:

有一些关于如何做到这一点的不错的教程：

• http://pio-tech.blogspot.ch/2012/01/using-spring-31-bean-definition.html
• http://steveschols.wordpress.com/2012/06/01/spring-3-1-unified-property-management-before-and-after/

• http://pio-tech.blogspot.ch/2012/01/using-spring-31-bean-definition.html
• http://steveschols.wordpress.com/2012/06/01/spring-3-1-unified-property-management-before-and-after/

we usually only use maven profiles to split the build into different parts for the developers and the continuous integration build. We don't actually use them for target environments anymore for the .war files. We still use maven profiles for automated database deployments, which differ more compared to the web-apps (amount of data, test-data, ...), but these are not delivered as a zip or so.

我们通常只使用 maven 配置文件将构建拆分为开发人员和持续集成构建的不同部分。对于 .war 文件，我们实际上不再将它们用于目标环境。我们仍然使用 Maven 配置文件进行自动化数据库部署，与 Web 应用程序相比，它的差异更大（数据量，测试数据，...），但这些并没有以 zip 格式提供。

There are surely other ways to go. I dont think its the end of the story :)

肯定还有其他方法可走。我不认为这是故事的结局:)

But it may help.

但它可能会有所帮助。

回答by PoloSoares

I happened to use properties-maven-plugin to set a system property depending on which maven profile was activated. Then in Spring, I was activating programmatically the profile(s) that I wanted, depending on that system property :

我碰巧使用 properties-maven-plugin 根据激活的 maven 配置文件设置系统属性。然后在 Spring 中，我以编程方式激活我想要的配置文件，具体取决于该系统属性：

String activeProfile = System.getProperty("myapp.profile");

String activeProfile = System.getProperty("myapp.profile");

appContext.getEnvironment().setActiveProfiles(....)

appContext.getEnvironment().setActiveProfiles(....)

Moreover, when I wanted to link directly the two kinds of profile (maven/spring), I was setting the spring.profiles.active property via the maven plugin.

此外，当我想直接链接两种配置文件（maven/spring）时，我是通过 maven 插件设置 spring.profiles.active 属性的。

Thoses practices are possibly wrong in the design but they solved my issues.

这些做法在设计中可能是错误的，但它们解决了我的问题。

回答by Matt

I think it depends on your requirements. If you have different dependencies based on the environment (ie. jdbc drivers, etc..), you'll want to use maven to sort this out.

我认为这取决于您的要求。如果您根据环境（即 jdbc 驱动程序等）有不同的依赖项，您将需要使用 maven 来解决这个问题。

If it's just a matter of configuring your deployment, you're probably better off using spring.

如果只是配置部署的问题，那么最好使用 spring。