为不同环境构建包的最便捷方法是什么？
我有一个 Maven 项目，它在生产环境和开发环境的属性文件中具有完全不同的设置。最常见的方法是使用不同的 Maven 配置文件（默认为 dev），它将在构建过程中打包不同的属性，对吗？ 也许还有其他方法吗？
I have a maven project, which has quite different settings in the properties files for production and development envs. Is it right, that the most common way is to have different maven profiles (dev by default) which will package different properties during the build process?
Is there maybe another way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，这正是配置文件的设计目的。
您甚至不需要不同的属性文件，您可以拥有 一个属性使用每个
配置文件中的不同属性进行过滤的文件。Yes, this is exactly what profiles are designed for.
You don't even need different properties files, you can have one property file that gets filtered with different properties from each
profile.配置文件的问题在于您需要运行配置文件的次数。这意味着如果有五个配置文件（开发、预测试、预上线、质量保证、产品），您需要运行构建五次。我建议采用不同的方式并直接生成已正确配置的五个工件（通常是战争等）。这可以通过使用我制作的示例来实现，这让生活变得更轻松。该示例将产生
The problem with profiles is that you need to run your build the number of times of your profiles. Which means if have five profiles (dev, pre-test, pre-live, qa, prod) you need to run your build five times. I would suggest to go a different way and produce as a result of a build direct those five artifacts (usually war's etc.) which have been configured appropriately. This can be achieved by using the example i have produced which makes life easiert. The example will produce
还有另一种方法可以将环境依赖项放入环境中，以便从 Maven 项目构建单个工件，然后在部署期间提供属性。在这种情况下，maven 对特定环境一无所知。
例如，您可以在 java 命令行中或使用 JNDI 或从数据库读取属性等方式放置一些
-Dmy.config.file=/path/to/env/my.properties内容。如果您有很多不同的环境或者您对它们一无所知（例如，向最终用户分发
.war应用程序），那么这是更可行的方法。There is another approach to put environment dependencies in an environment to have single artifact built from maven project and then provide properties during deployment. In this case maven doesn't know anything about particular environment.
E.g. you could put something
-Dmy.config.file=/path/to/env/my.propertiesin java command line or by using JNDI, or reading properties from database, and so on.This is more viable approach if you have a lot of different environments or you don't know anything about them (e.g. distributing a
.warapplication to end-users).