Usage of distribution plugin

plugins

(AlexLG) #1

Hello,

I’m trying to understand the usage of distribution plugin as task dependencies for the plugin doesn’t seem logical for me.

For instance, the execution of distZip task is done before the assemble task because it depends on it. As I can understand from the Gradle code, the dependency is done because the distZip/Tar define an archive and assemble tasks depends on that.

So, the execution order looks like this for a gradle build distZip:

:distTar UP-TO-DATE
:distZip UP-TO-DATE
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar
:assemble
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test UP-TO-DATE
:check UP-TO-DATE
:build

with this build.gradle:

apply plugin: 'java'
apply plugin: 'distribution'

As you can see, the distZip task is the first to execute and then doesn’t contains any of the build after.

Am I missing something and the distZip task has to be execute first or is this a bug ?

Thanks in advance for any help,
Regards,
Alex


(James Justinic) #2

By default, only files in the src/main/dist folder are included in the distribution. If you don’t have a src/main/dist folder and don’t add any additional files to the distribution, the distTar and distZip tasks don’t have any inputs, so will always be UP-TO-DATE.

The purpose of the assemble task is to assemble all archives in the project, including the jar. However, unless you include the jar in the distribution there’s neither a distTar/distZip task dependency on jar nor a reason for distTar/distZip to run in any specific order.

If you want the jar in the distribution, your build.gradle should look something like:

apply plugin: 'java'
apply plugin: 'distribution'

distributions {
    main {
        contents {
            from jar
        }
    }
}

(Hoobajoob) #3

How do I control where in the distribution the jar will be placed? Specifically, I need it to land in the ‘lib’ folder.

I’m actually using the java-library-distribution plugin, which drops dependencies in the lib folder of the distribution. But, I want the jar in lib as well, not just its dependencies.


(Hoobajoob) #4

This is closer, but it still drops the built jar file in the base directory for the distribution. Is there a way to get the built jar + dependencies all into the lib folder (and nowhere else)?

distributions {
  main {
    contents {
      into ('lib') {
        from jar
      }
    }
  }
}


(AlexLG) #5

Hi James,

That’s the trick !

Many thanks,
Alex


(James Justinic) #6

This probably should have been a different topic as you’re not using the same plugin or asking the same question.

However, I think that you probably should be using the distribution plugin rather than the java-library-plugin based on what you’re wanting to build. The java-library-plugin applies the distribution plugin and configures it to put the jar file in the root and the dependencies in the lib folder, plus including an additional src/dist folder, so you’re probably getting more things you don’t want by using it.

This would be what the java-library-plugin is doing, but just with exactly what you explicitly asked for:

apply plugin: 'distribution'    

distributions {
    main {
        contents {
            into('lib') {
                from jar
                from(project.configurations.runtime)
            } 
        }
    }
}

(Hoobajoob) #7

@jjustinic: fantastic - that (by that, I mean: use the distribution plugin, and change the contents block as you describe above) was it! So simple.
@alexlg: sorry for kind of repurposing your thread. Hopefully this whole thing ended up being relevant and useful to the original request.


(Mary Ann Davison) #8

Is this plugin what I’m looking for? I’m just not sure. I need to create a zip that includes:
executable artifact
configuration files
documentation (getting started, for example)

I’m thinking of a directory structure like:
/dist/docs
/dist/config
/dist/build

We’re not releasing source and we’re creating an executable so we don’t distribute the jars individually - just the executable customers can use

Is this plugin one I can use to make an arbitrary folder structure in my zip file?

Thanks!
Maffy


(Hoobajoob) #9

Yes, we have a specific distribution folder structure that we need, and we’re able to lay it out through a combination of the folders we place under src/main/dist and copy specs in the distributions configuration block like so:

distributions {
  main {
    contents {
      baseName = 'top-level-folder-name'
      into ('lib') {
        from jar
        from (project.configurations.runtime)
      }
    }
  }
}

(Mary Ann Davison) #10

The problem is that the project is a python project, so the structure of the project doesn’t have a src/main/java or groovy. Right now I have this:

task createZip(type: Zip, dependsOn: makeExecutable) {
outdir file(‘build’)
from ‘dist’
}

Which does move the executable created by pyinstaller into the zip file in the build directory. Now I want to add files from /doc and /config into the zip file, too. I thought that the distribution plugin would help but it looks like it wants a specific layout.


(Mary Ann Davison) #11

It appears to be working now - not sure why it didn’t before. The zip now contains the executable and config file and an example. I just have to make sure it gets all the configs and samples, but it’s looking good.


(Lori Small) #12

I tried this but I get 2 copies of every jar in my lib directory. If I use only “from jar”, I get 2 copies of my application jar and a single copy of the dependency jars. If I use “from (project.configurations.runtime)”, I get 2 of every dependency and a single copy of my application jar. If I use both, I get duplicates of every jar. Can you advise?


(Lori Small) #13

If I use the foloowing:

distributions {
main {
contents {
baseName = 'workflow-migration-utility’
into (‘lib’) {
}
}
}
}

I get a single instance of each jar. Has something changed to imply all project jars are selected by default? I am using gradle version 2.10:


Gradle 2.10

Build time: 2015-12-21 21:15:04 UTC
Build number: none
Revision: 276bdcded730f53aa8c11b479986aafa58e124a6

Groovy: 2.4.4
Ant: Apache Ant™ version 1.9.3 compiled on December 23 2013
JVM: 1.8.0_65 (Oracle Corporation 25.65-b01)
OS: Windows 7 6.1 amd64