我见过几个我工作的项目,它们在项目中使用profiles.xml和各种{username} .properties来开发沙箱设置,例如部署脚本的部署目录,要运行的端口,哪个数据库和Web现在Maven 3已经删除了对profiles.xml的支持,这让我完全质疑这种做法。所以我有几个问题:
答案 0 :(得分:1)
正如您所说,Maven 3仅删除了对外部profiles.xml文件的支持。您仍然可以在settings.xml中使用配置文件,并且一如既往地在pom.xml中使用配置文件。那些当前具有外部profiles.xml文件的项目应该将这些配置移动到本地用户的settings.xml文件中。
1)确实没有比配置文件配置更好的机制来管理环境特定值。
2)scm中的用户属性文件取决于您拥有的内容以及该信息是否对可能查看它的其他人敏感。如果您正确构建源树,那么将它存储在SCM中应该没有问题。
3)在过去与我合作的其他项目中,我们在标签,主干和分支旁边保留了一个单独的目录,其中SVN称为配置,其基本目录包含配置文件的模板( s)应该看起来像开发人员文件夹和服务器目录。在基本目录中,开发人员将在具有自己的配置文件副本的开发人员目录下创建/分支他们自己的目录。这允许他们将更改合并到基本版本并更新“他们的”配置。这解决了很多服务URL的变化,并允许他们按时完成。
4)不是线索。可能是Maven 1的一个障碍,他们想要删除。
哦,不要忘记,使用Maven 2.2和3.0,您可以加密settings.xml中的值。
答案 1 :(得分:0)
是否有更好的机制而不是配置文件来实现这一目标?
不,简介仍然是完美的。
如果没有,你觉得{username} .properties属于scm吗?有时(例如)当服务URL发生变化时,我们忘记更新所有开发人员的属性。
我通常会将用户特定的属性放在~/.m2/settings.xml
文件中的pom.xml
和常用属性中。
如果在scm中包含这些属性文件并不是一个坏主意,那么开发人员沙箱之间常见的设置是否应该有某种配置文件继承?怎么可能这样做?
如果您想从继承中受益,我的建议是使用maven <properties>
。
作为旁注,你知道为什么Apache在Maven 3中删除了对profiles.xml的支持吗?
profiles.xml
的支持使得Maven内部结构复杂且难以测试。并且因为在大多数情况下使用settings.xml
是可接受的替代方案,所以profiles.xml
已被删除。请参阅following thread(特别是Jazon的消息)。