Gradle - 什么时候插件比脚本更好？
我正在使用 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/jetty？
非常感谢您的想法！
I'm using gradle to manage a multi-project J2EE build - the end-goal is to produces a series of server package/artifacts that can be deployed to a target server, unzipped, and run.
In other words, each artifact contains everything it needs to run - minus the JDK.
The project structure looks somewhat like so:
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
Building common, apps and webapps as dependencies of each other is pretty straight-forward but building the servers projects have proven to be somewhat of a challenge.
My current approach is to use a bare-bones server in the "servers" folder and copy it's contents over to the taget server being built, then copy war files to it and zip it all up... but my root/servers/build.gradle is starting to look a mess.
So the question is -- would writing an 'ear' style plug-in help simplify my server builds?
Also of note, I'm currently using resin-pro-3.0.25 but planning on switching to another server container soon (next couple of months), which brings me to a tangent question - are other folks using similar approaches when building server artifacts for tomcat / jetty?
Your thoughts are greatly appreciated!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我认为在单独的脚本中分离捆绑逻辑总是值得的，因为它还简化了在另一个项目中的使用。另请注意，您不一定需要编写插件来完成此任务 - 您可以从
buildSrc目录。我猜想
:servers的子项目存储了一些要注入到可分发中的配置，因此您的结构对我来说很有意义。然后，该脚本将定义一个新任务，该任务将按照约定检索所有文件（:servers项目的通用目录结构，从同名的:webapps子项目中获取 WAR我们正在被处决的那个......）。至于你的最后一个问题，我认为这取决于目标操作系统——例如，如果是 Debian，可能会生成一个仅包含应用程序 WAR 和配置并依赖于容器包（来自官方存储库或由您构建）的包对我来说更自然。
I think that separating bundling logic in a separate script is always worthwhile, because it also simplifies using it in another project. Also note that you don't necessarily need to write a plugin to accomplish this task -- you can start with script in
buildSrcdirectory in the main project.I guess that subprojects of
:serversstore some configuration to be injected into distributable, so your structure makes sense to me. The script would then define a new task that would retrieve all the files by convention (common directory structure for:serversproject, taking WAR from:webappssubproject of the same name as the one we're being executed on...).As for your last question, I think that this depends on target OS -- e.g. if it's Debian maybe producing a package that contains only the application WAR and configuration and depends on the container package (either from official repo, or built by you) would be more natural for me.