Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Gradle multi project distribution

Tags:

I'm trying to make a dist of a multi project build. The root project looks something like this:

apply plugin: 'distribution'
version 1.0
distributions {
    main {
        baseName = 'someName'
        contents {
            from 'nodes' 
        into 'nodes'
        }
    }
}

It just copies a folder with some files to the dist.

I now want each subproject to inject its stuff into the dist. I want to add each subprojects jar, any dependecies, and possibly some other files etc...

I have no idea how to inject from the subproject to the root. Should I even do something like that? What i mean is something like this:

subprojects {
   apply java...
   ...

   // pseudocode
   jack into the root project dist plugin
   put my produced jars and dependencies in a folder with my name
   ...
}

Does anyone have any examples, or just point me in the right direction?

thanks!

like image 327
Sason Ohanian Avatar asked Jul 17 '13 20:07

Sason Ohanian


People also ask

Should I use buildSrc?

buildSrc should be preferred over script plugins as it is easier to maintain, refactor and test the code. buildSrc uses the same source code conventions applicable to Java and Groovy projects. It also provides direct access to the Gradle API.

What is subproject in Gradle?

The subproject producer defines a task named buildInfo that generates a properties file containing build information e.g. the project version. You can then map the task provider to its output file and Gradle will automatically establish a task dependency. Example 2.

What is distribution in Gradle?

The Distribution Plugin facilitates building archives that serve as distributions of the project. Distribution archives typically contain the executable application and other supporting files, such as documentation.


2 Answers

I was looking for the same thing. With some peeking at the API docs and Gradle' own build files, I came to the following:

apply plugin: 'distribution'

distributions {
    main {
        contents {
            into('bin') {
                from { project(':subproject1').startScripts.outputs.files }
                from { project(':subproject2').startScripts.outputs.files }
                fileMode = 0755
            }
            into('lib') {
                def libs = []
                libs << project(':subproject1').configurations.runtime - project(':runner').configurations.runtime
                libs << project(':subproject2').configurations.runtime
                from libs
                from project(':subproject1').jar
                from project(':subproject2').jar
            }
        }
    }
}

The contents {} closure is a CopySpec, knowing that makes using the distribution plugin way simpler :)

Check out Gradle' own subprojects/distributions/distributions.gradle file for some great examples of using the CopySpec.

This works.

  • The substraction is to remove duplicated jars.
  • The ".jar" lines are to add the jar of that project as the configurations.runtime only seem to contain the dependenceis.

Sadly, currently I've no clue on how to scale this to more than two projects in a clean way. Atleast we're one step closer :)

like image 119
pvdissel Avatar answered Oct 22 '22 04:10

pvdissel


I found a solution that has been working well for me. The key is that you add a separate subproject for creating the dist. This subproject is sibling to the other subprojects. That is, do not try to script the distribution in your top-level build.gradle file.

Let's call the new subproject dist. The first thing to do is to add it to your top-level settings.gradle file in your multi-project root:

include "subproject1", "subproject2", "subproject3", ....... , "dist"

Your dist project must at minimum include:

  • build.gradle - to be detailed below
  • src/main/dist/at_least_one_dummy_file.txt - the distribution plugin always requires a src/main/$distribution.name directory. Having a non-empty one with a distribution.name of main tricks the plugin into following all the transitive dependencies of all the main sourcesets of all the sibling projects.

Next, the build.gradle file for the dist project:

/* Hook in all sibling project jars and their transitive dependencies */
apply plugin: 'java'
dependencies {
    compile project(':subproject1')
    compile project(':subproject2')
    compile project(':subproject3')
    . . . 
}

/* Distribution */
apply plugin: 'java-library-distribution'
distributions {
    main {
        baseName = "your-top-level-project-name"
        contents {
            exclude "dist-${version}.jar"
            . . . 
        }
    }
}

Then run gradle distZip. The ZIP file in dist/build/distributions will have a lib subdirectory with every single JAR you want: the sibling project JARs and their transitive dependencies.

Because of the trickery we used, the distribution plugin will make an empty JAR called dist-${version}.jar. For cosmetic reasons, I remove it with the exclude call above, but it is harmless. You could also use a second exclude call to remove the at_least_one_dummy_file.txt if there really is no content under src/main/dist that you want to include. If you do not want add any artifacts and/or remove the ones mentioned here, then you don't even need a contents section at all.

I also have found ways of selectively including different artifacts based on whether this is a "dev" or "prod" distribution, a la Maven profiles. If you want me to add that, please post in comments and I will.

like image 43
sparc_spread Avatar answered Oct 22 '22 05:10

sparc_spread