在Gradle中创建具有附加编译依赖性的生产配置

Question

我正在尝试为生产版本定义构建脚本。

下面是项目结构，所有项目都是java插件。

wrapper (parent)
|--frontend (child)
|  |--src
|  |  |--js (raw ES6 modules)
|  |  |--sass (raw)
|  |--build
|     |--lib
|     |  |--production-front.jar
|     |--dist
|        |--js (bundled)
|        |--css (compiled production)
|--backend (child) (spring boot)
   |--build
      |--lib
         |--RELEASE.jar

现在，这里发生的是sourceSets.main.resources.srcDirs的默认（backend）直接链接到：

• 原始 :frontent/src/js
• 生成的 :frontent/build/dist/css。

这样，当您运行它时，默认情况下它将处于开发模式。在这里，这意味着它将：

• 使用生成的 scss-> css文件（这是资源，例如，如果您运行后台gulp-sass并在每次更改scss时对其进行编译，则css将会更新并繁荣，开发周期很快） 。
• 使用直接在浏览器（JSPM，SystemJS，Babel）中编译的 raw JS-因此，您只需要编辑:frontent/src/js并刷新页面即可。

好的，所以尽管开发人员是爱人，但我还需要进行编译以进行生产。上面提到的项目结构还显示了:frontend在哪里生成production-front.jar。

这是带有注释的默认Java构建树。

编辑 我需要进行依赖，将production-front.jar编译成RELEASE.jar并省略提到的附加资源。

请注意，我只需要省略那些资源，而无需main.resources.srcDirs中的任何其他资源。

解决此问题的正确方法是什么（一种不执行例如从.jar中删除开发资源，然后放入其他production-front.jar的任务）？我不知道如何制作多个可以在这里工作的sourceSet或配置。

Answer 1

在过去一周的时间里，我对Gradle进行了非常深入的学习（创建该主题是因为我快要退休了），我终于找到了非常令人满意的解决方案。

我想分享一下我的目标和最终解决方案：

• 具有最小的build.gradle
• 有可能与build --continuous一起发展
• 进行此操作，以便eclipse插件（可能还包括其他IDE）可以完美以其自己的构建系统镜像纯命令行Gradle开发。

这是一个多项目，其中之一是带有DevTools的Spring Boot应用程序。

wrapper (parent)
|--frontend (child)
|  |--src-client
|  |  |--static
|  |  |  |--img (images)
|  |  |  \--js (raw ES6 modules)
|  |  \--sass (raw, note not in static folder)
|  \--build
|     |--lib
|     |  \--front.jar
|     |--dist
|     |  |--js (bundled, minimized)
|     |  \--css (compiled production, minimized)
|     \--dev
|        \--css (compiled dev, compact readable format)
\--backend (child) (spring boot)
   |--src
   |  |--main/java
   |  |--main/resources
   |  \--test/java
   \--build
      \--lib
         \--application.jar

正如我所描述的，目标是：

• bootRun与js和 compiled css的原始源一起运行，并且与backend的{ {1}}。
• 已将main编译为生产版本，并且依赖已编译的bootJar，而不是dev中使用的所有内容（上一点）。

我使用了配置，sourceSets和bootRun属性的组合（很多时间）。

以下是文件（向下细分）：

wrapper / build.gradle

front.jar

wrapper / front / build.gradle

wrapper.gradleVersion '5.0-milestone-1'

allprojects {
    apply plugin: 'eclipse'
}

包装器/后端/build.gradle

plugins {
    id 'java' // possibly use java-base or just custom zip task, since client doesn't actually compile java
}

jar {
    dependsOn buildProduction // task that compiles my stuff into build/dist
    baseName 'front'
    classifier 'SNAPSHOT-' + new Date().format('yyyyMMddHHmmss')
    from(buildDir.absolutePath + '/dist') {
        into 'static'
    }
}

// Note there is a lot of other tasks here that actually compile my stuff, like gulp-sass and JSPM bundling with babel transpiler.

一些有助于以下方面的链接： http://mrhaki.blogspot.com/2014/09/gradle-goodness-adding-dependencies.html

请注意，客户端的源文件夹称为buildscript { repositories { mavenCentral() maven { url 'https://repo.spring.io/milestone' } } dependencies { classpath 'org.springframework.boot:spring-boot-gradle-plugin:2.1.0.RC1' } } apply plugin: 'java' apply plugin: 'org.springframework.boot' apply plugin: 'io.spring.dependency-management' sourceCompatibility = 10 // eclipse has (or had) problems with Java 11 targetCompatibility = 10 sourceSets { // 'java' plugin adds default main sourceSet dev { resources.srcDirs = [ project(':front').projectDir.absolutePath + '/src-client', project(':front').buildDir.absolutePath + '/dev' ] } } bootJar { baseName 'application' classifier 'SNAPSHOT-' + new Date().format('yyyyMMddHHmmssSSS') // I used bootArchives since it was already there and my stuff fits description, you can also define your own configuration and extend runtime one. classpath configurations.bootArchives } bootRun { sourceResources sourceSets.dev // I make bootRun (dev) use dev sourceSet } dependencies { runtime 'org.springframework.boot:spring-boot-devtools' // Since bootArchives configuration is used only by bootJar (not bootRun), this will be only in final fat .jar bootArchives project(':front') ... } repositories { mavenCentral() maven { url 'https://repo.spring.io/milestone' } } ：这是在Eclipse中制作“ 完美镜像”的关键。如果我们将其命名为src-client，而src已在main eclipse中使用，则会出现名称冲突（可能可以通过配置eclipse插件来解决，但会再次出现-我们想要为简单起见，无需进行IDE配置）。

最终结果是，我们通过gradle的连续构建获得了非常不错的命令行开发，并且在eclipse中完全镜像了行为，从而默认配置以相同的方式工作（但是使用eclipse的builder而不是gradle的builder）。在backend项目中，我们还可以很好地链接到backend中使用的源的文件夹。同样可能适用于IDEA：）。