groovy - 在构建过程中在源中设置 "hard-coded"标志

Question

我正在开发一个(Groovy)应用程序，它是通过 Gradle(在持续集成服务器上)构建的。该应用程序应编译为两个版本:一个开发版本(包括我只想为自己启用的一些功能)和一个公共(public)版本(不包括或仅禁用这些“开发功能”)。

对此的一种解决方案是在应用程序的主类中直接使用全局标志之类的东西，例如 static final boolean PUBLIC_RELEASE .然后在我的代码中，我可以检查该标志并启用或禁用某个功能。

现在在我的 Gradle 构建脚本中，我可以检查环境变量(由持续集成服务器设置)。如果设置了该变量，那么我可以将标志的当前值设置(即更改)为 true或 false在编译源代码之前。

我相信这种方法会奏效。但是，在构建过程中自己修改源代码感觉不对。另一方面，我认为这是许多软件项目的标准任务。

是否有任何“最佳实践”来处理此要求？

Answer 1

可以制定出三种处理场景的方法 - 以我会这样做的方式排序:

创建一个专用的属性文件，在构建期间过滤并添加到最终的 jar 中。应用程序行为由该文件在运行时确定。基本上这是处理这种情况的方式，但是用户可以直接在 jar 中修改此类文件。

源码过滤，提示ReplaceTokens .这似乎是保护应用程序的最佳方式，因为行为直接编译成代码，但在过滤方面也存在问题。

通过传递系统属性-D 来配置应用程序的行为在运行时。有可能应该传递许多此类属性，因此可能会给最终用户带来问题，并且应用程序的配置被明确公开。