0

我正在使用 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 /码头？

非常感谢您的想法！

4

1 回答 1

0

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

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

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

于 2011-05-27T10:05:32.420 回答