在 Gradle 应用程序插件中部署其他文件
我有一个小型 Java/Gradle 项目。我正在使用 应用程序插件 创建 zip 发行版(使用 distZip 任务)。使用标准配置,我在 zip 文件中获得以下目录:
/bin - 启动应用程序的脚本位于此处
/lib - 在 JAR 文件和所有依赖 JAR 文件中包含我的项目代码。
问题是我想要第三个目录: /conf ,我可以在其中放置我的配置文件(而不是将它们打包在我的应用程序 JAR 文件中)。
我想这是一个非常常见的要求,因为事情像 log4j.xml 和 hibernate.properties 这样的文件最好放在 JAR 文件之外,但是我不知道如何自定义应用程序插件的行为来执行此操作。
I have a small Java/Gradle project. I'm using the Application plugin to create a zip distribution (using the distZip task). Using the standard configuration I get the following directories in my zip file:
/bin - The scripts to start the application go in here
/lib - Contains my project code in a JAR file and all dependency JAR files.
The trouble is that I would like a third directory: /conf where I can put my configuration files (instead of having them packaged inside my application JAR file.
I imagine that this is a pretty common requirement because things like log4j.xml and hibernate.properties would be better placed outside the JAR file. I just can't figure out how I can customise the behavior of the Application plugin to do this however.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(5)
几个月后我重新审视了这个问题,终于有了一个优雅的解决方案。应将以下代码添加到 gradle 文件中:
这会向 distZip 任务添加额外的包含内容。这会将“conf”目录(包括内容)复制到 Zip 发行版中。
生成的 zip 文件包含一个与项目名称相同的目录。这就是为什么需要“进入”部分。
I revisited this problem several months later and I finally have an elegant solution. The following code should be added to the gradle file:
This adds an additional include to the distZip task. This copies the "conf" directory (including contents) into the Zip distribution.
The generated zip file contains a single directory which is the same as the project name. This is why the "into" part is required.
实际上,在项目的
src
目录下创建一个dist
目录。当 installApp 或 distZip 运行时,应用程序插件(在applicationDistribution
下)会复制此目录中的所有内容。如果简单的副本还不够的话,或者编辑
applicationDistribution
来做其他事情。Actually, create a
dist
dir under thesrc
dir in your project. Anything in this dir is copied by the application plugin (underapplicationDistribution
) when installApp or distZip is run.Or edit
applicationDistribution
to do other things, if a simple copy is not enough.对我来说,一个简单的
任务就完成了。当然,您需要从代码中正确加载属性。特别是如果您将它们从可通过类路径使用的 src/main/resources 移动到新位置。我通过添加一个指向配置文件的命令行参数来规避这个问题。
For me, a simple
did the job. Of course you need to have your properties loaded correctly from within code. Especially if you move them from src/main/resources where they have been usable via classpath, into the new location. I circumvented this by adding a command line parameter which points to the configuration file.
我不确定是否可以自定义应用程序插件,我从未使用过它。然而,还有其他方法可以实现您想要实现的目标。
您可以像这样创建一个
/conf
目录:然后您可以将所需的文件复制到该目录中,如下所示:
然后您可以将此复制任务挂接到该进程中,如下所示:
最后,如果您不这样做如果您想要在最终的 zip 中进行配置,您可以这样做:
同样,可能有更好的方法。这是一种方式。
I am not sure whether you can customize the application plugin, I have never used it. There is however other ways to achieve what you want to achieve.
You may create a
/conf
directory like this:You can then copy the files you need into this directory like this:
You may then hook this copy task into the process like this:
And last if you do not want your configurations in the final zip, you can do this:
Again, there might be a better way. This is a way.
OP 的自我回答可能适合他的用例,但有一些我想改进的地方:
build.gradle 并行的目录
。 Maven中没有这样的标准目录布局。普遍的共识是拥有一个 src/main/conf ,正如文档中暗示的那样:conf
。 gradle如果需要资源过滤(而且经常如此),那么最好有一个单独的任务。本地开发时,可以运行该任务生成过滤后的文件。该发行版将仅使用此任务的输出(与 OP 的答案不同,这也使
conf
可用于 tar 发行版)。OP's self-answer may be good for his use case, but there are a few things I'd like to improve on:
conf
parallel to thebuild.gradle
. There is no such thing in the Maven Standard Directory Layout. The general consensus is to have asrc/main/conf
as had been hinted to in the docs:The target directory name is NOT
project.name
as had been pointed out in a comment.If resource filtering is required, and it often is, then having a separate task is desirable. During local development, this task can be run to generate the filtered files. The distribution would merely use the output of this task (and unlike OP's answer, this also makes
conf
available to the tar distribution).