我在一个大型遗留项目中工作，我注意到在项目根pom中，我们明确强制使用了某些maven插件版本。
我读过关于"maven方式"的文章，在我看来，这违反了这种方式——强制版本，而不是从超能力继承它们。以下是我们在pom项目中的一个例子：
<build>
<plugins>
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.3.2</version>
<configuration>...</configuration>
</plugin>
我的问题是，强制使用这样的插件版本的正当理由是什么（如果有的话）。我想知道，因为我经常发现编写的代码没有任何明确的目的，我确实想知道是否是这样的情况，以及我是否应该将版本从项目根pom中删除。
事后思考：在这个网站上他们说：
在内部声明"正常"版本（如Junit的3.8.2）时这表示为"允许任何事情，但更喜欢3.8.2。"这意味着当检测到冲突时，允许Maven使用该冲突算法来选择最佳版本。如果指定[3.8.2]，则意味着只使用3.8.2，不使用其他内容。
因此，这意味着，如果你强制版本以确保稳定性，那么你也应该使用[]，否则maven可以自由忽略你的强制版本。
最好的方法是仅在公司pom中定义插件版本，当然，随着时间的推移，也就是说不时更新插件版本。
这意味着，在任何其他项目中，都不需要或更好地防止使用不同版本的插件（除非插件中出现这种错误有很好的原因）。
此外，您给出的摘录是一个不良实践的例子，因为插件和/或它们的配置应该使用pluginManagement来定义。
因此，如果一个项目需要一个旧版本的maven插件，那么pom中至少应该有一条注释，描述为什么它使用的不是继承版本。可能有一个链接到适当的JIRA问题。。。
有什么合理的理由（如果有的话）强制使用这样的插件版本。
一个合理的理由是保持构建的可重复性，尤其是在插件的后续版本存在已知问题的情况下。这确保了使用特定版本，而不是来自组织父pom的更高版本（或者，更糟的是，来自任何地方都没有指定版本的默认版本）。
我想知道，因为我经常发现编写的代码没有任何明确的目的，我确实想知道是否是这样的情况
在大型代码库中，很有可能正是这种情况。插件配置可能是从其他地方复制的，并且包含的版本没有充分的理由。
以及我是否应该从项目根pom中删除该版本。
如果没有给出任何原因，无论是在评论还是提交消息中，如果同一个插件在父pom和中指定了版本，如果没有它，构建仍然可以完美运行，那么你应该删除该版本。
如果不起作用，您应该修复构建或添加一条注释，解释为什么需要此版本。
如前所述，这可能是由于公司原因——使用新版本的插件可能会破坏测试、功能甚至整个产品本身；新版本必须经过彻底测试，高级团队甚至需要讨论它们，因为它可以通过多种方式更改产品。
不强制版本会在下一次大型构建中造成某种不稳定的情况——这总是不必要的，开发人员不喜欢随机性：）。如果你的POM只描述了一个小型的私人项目，甚至可能是一个小型社区项目，你很可能会让maven来做所有的版本管理，但对于值得的专业产品来说，这几乎是不可能的。。。。比如数十万甚至数百万的货币单位。