Customize the root folder of an archive created by the Distribution plugin


(laurentdroin) #1

I’m trying to use the Distribution plugin (Gradle 1.12) and (of course), I need to customize some of its operations but I can’t seem to make my customization work.

The first thing I need is to customize the root folder in the archive. Say I want to call it “rootFolder” for example instead of the default generated name (let’s call it defaultRootFolder to make this description more simple).

I looked in the source code at how the distribution tasks are created, and it appears that in my build script, I can access them and change their configuration.

The first thing I tried was:

tasks.windowsDistTar.into(‘rootFolder’)

When I do that, I correctly have the root folder of my archive called ‘rootFolder’, which is great, but inside, there is an extra folder called ‘defaultRootFolder’. I wondered how this could happen and looked at the source code, from the Zip task class all the way up to the AbstractCopyTask class. I discovered that an copy task (like Zip) has two copy specs, a root one (rootspec), and a child one (mainspec). In the distribution plugin, calling the into method on the zip task that takes a path and a closure uses the path for the main spec, not the root spec (at least, that’s my understanding). So I tried this:

tasks.windowsDistTar.into(‘rootFolder’)

tasks.windowsDistZip.mainSpec.into(‘blop’)

I ended up with an archive that has the root folder called ‘rootFolder’, that contains a folder called ‘blop’. I thought it all made sense and maybe I didn’t have to change the ‘into’ of rootSpec and could just change the one on mainSpec (I want one root folder only, not a root folder and a subroot folder).

So I just did

tasks.windowsDistZip.mainSpec.into(‘rootFolder’) Unfortunately, this caused the root folder to be called ‘rootFolder’ (great) BUT it did contain a subfolder called ‘defaultRootFolder’, which I don’t want.

How can I get just one root folder in my archive, and specify its name?

Thanks in advance.


(Peter Niederwieser) #2

‘applicationName = “rootFolder”’ should have the desired effect. Alternatively, you could modify archive entry paths using ‘windowsDistZip.eachFile { … }’, define your own Zip task, or use the more recent ‘distribution’ or ‘java-library-distribution’ plugins, which appear to be more configurable than the ‘application’ plugin.


(laurentdroin) #3

Thanks Peter. Note that I am using the Distribution plugin (not the Application plugin), hoping that it will remain in Gradle 2.0 since I’m investing in using it. applicationName doesn’t seem to make a difference in my archive structure.


(Peter Niederwieser) #4

Check the user guide chapter for the ‘java-library-distribution’ plugin. I think the same works for the ‘distribution’ plugin.


(laurentdroin) #5

Thanks. It looks like the java-library-distribution user guide chapter is even more terse :wink: I am still looking into it, trying to understand how I can override the value for “into” that is being passed at task (dynamic) creation and also trying to understand why there can be both a root folder and a “subroot” folder in the archive. There must be a solution to this. I’m trying to stay away from messing with rootSpec and mainSpec as they look like internals and I’d really like to stick to public API if possible.


(Peter Niederwieser) #6

I think you can just change the distribution’s ‘baseName’ as shown in that chapter. The two ‘Zip’ task related solutions I mentioned should also work.


(laurentdroin) #7

It looks like I can’t customize the Distribution plugin enough for my needs. I won’t be able to have enough control of the “into” part. It’s hard-coded to use the archive name, which can be customized (but then it affects the actual archive name, and I need the root folder name and the archive name to be different). The archive name, if not customized, will use the baseName, but that means I can’t customize the archive name anymore. So in the end, I will have to give up the Distribution plugin (I have too many constraints) and use my own Zip task. It should not be very difficult, especially since there is a lot of documentation.