plugins - Gradle - 什么时候插件比脚本更可取？

Question

我正在使用 gradle 来管理多项目 J2EE 构建——最终目标是生成一系列可以部署到目标服务器、解压缩和运行的服务器包/工件。

换句话说，每个工件都包含它运行所需的一切——减去 JDK。

项目结构看起来有点像这样:

Root project 'proto' - This is the master-build project
+--- Project ':applications' - Default build settings for applications
|    +--- Project ':applications:foo' - Foo API
|    +--- Project ':applications:bar' - Bar API
|    \--- Project ':applications:baz' - Baz API
+--- Project ':common' - Common code shared by multiple projects
|    \--- Project ':common:subcomponents' - Settings shared by subcomponents
|         +--- Project ':common:subcomponents:configuration' - Configuration
|         \--- Project ':common:subcomponents:initializer' - Initializers
+--- Project ':servers' - Default tasks for building server artifacts
|    +--- Project ':servers:foobar' - Assembles and runs the foobar server
|    +--- Project ':servers:foobaz' - Assembles and runs the foobaz server
|    \--- Project ':servers:barbaz' - Assembles and runs the barbaz server
\--- Project ':webapps' - These are the defaults for webapps
     +--- Project ':webapps:foo' - The webapp for foo
     +--- Project ':webapps:bar' - The webapp for bar
     \--- Project ':webapps:baz' - The webapp for baz

将通用、应用程序和 web 应用程序构建为彼此的依赖关系非常简单，但构建服务器项目已被证明有些挑战。

我目前的方法是在“servers”文件夹中使用一个准系统服务器并将其内容复制到正在构建的taget服务器，然后将war文件复制到它并将其全部压缩......但是我的root/servers/build .gradle 开始看起来一团糟。

所以问题是——编写一个“耳朵”风格的插件会帮助简化我的服务器构建吗？

另外值得注意的是，我目前正在使用resin-pro-3.0.25，但计划很快(接下来几个月)切换到另一个服务器容器，这给我带来了一个切题的问题——其他人在构建服务器工件时是否使用类似的方法为tomcat/码头？

非常感谢您的想法!

Answer 1

我认为在单独的脚本中分离捆绑逻辑总是值得的，因为它还简化了在另一个项目中的使用。另请注意，您不一定需要编写插件来完成此任务——您可以从 buildSrc directory 中的脚本开始。在主项目中。

我猜 :servers 的子项目存储一些要注入(inject)可分发的配置，因此您的结构对我来说很有意义。然后脚本将定义一个新任务，该任务将按约定检索所有文件(:servers 项目的通用目录结构，从 :webapps 子项目中获取 WAR，与我们正在执行的项目同名...) .

至于你的最后一个问题，我认为这取决于目标操作系统——例如如果它是 Debian 可能会生成一个仅包含应用程序 WAR 和配置并依赖于容器包(来自官方 repo 或由您构建)的包对我来说会更自然。