This message was deleted.

sure, that should be possible in a few ways The application plugin has a task to build the zip, and it also has a preparatory task that creates a directory of the files that go into the zip. Create a new Zip task that uses that prep-task, and does some juggling to get the files sorted. Alternatively, use the ‘fat jar’ example, but instead of a Jar task, use a Zip task https://docs.gradle.org/8.1.1/userguide/working_with_files.html#sec:creating_uber_jar_example

Thanks, Adam! I went with regular

Zip

and

Copy

tasks now:

val distCopySpec = copySpec {
    val jar = tasks.getByName<Jar>("jar")

    from(jar)
    from(configurations.runtimeClasspath)
}

tasks.register<Copy>("distTest") {
    with(distCopySpec)
    into(distsDirectoryTest)
}

tasks.register<Zip>("distZip") {
    with(distCopySpec)
}

looks a bit confusing, but if it works, it works :)

Do you have any recommendations how to improve it? 🙂

my one note would be that Sync tasks are usually better, because they will clear out old files. For example, if you remove a dependency then you don’t want that dependency to linger in distsDirectoryTest. A Copy task will keep it, while a Sync task will remove it.

For context: I'm building a Debezium plugin and need the exploded distribution (i. e. all JAR files) in a local directory for testing and the layout in the tests distribution should be the same as in the final ZIP archive, hence the shared

CopySpec

.

ahh okay, that makes more sense

Thanks for the hint about the Sync task. I didn't know about that one. ❤️

What I’d suggest is flipping the order of your tasks. First task builds the zip, and the 2nd task unpacks the zip into the test directory. Then you don’t have to share the copySpec, and you can be more sure that you’re testing the actual distribution.

Makes sense, thanks! I've ended up with this now:

val distsDirectoryTest = project.distsDirectory.dir("test")
tasks.register<Zip>("distZip") {
    val jar = tasks.getByName<Jar>("jar")
    from(jar)
    from(configurations.runtimeClasspath)
}

tasks.register<Sync>("distTest") {

    from(zipTree(tasks.named<Zip>("distZip").map { it.archiveFile }))
    into(distsDirectoryTest)
}

looks good!

One more note to answer the initial question. What you actually are after is the

distribution

plugin. The

distribution

plugin is the one providing the

distZip

,

distTar

and

installDist

tasks. The

application

plugin and also the

java-library-distribution

plugin just apply the

distribution

plugin and then configure the

main

distribution, e.g. defining that the dependencies are copied to

libs

. So while you of course can just write own tasks, you could also apply the

distribution

plugin and configure the

main

distribution however you need it. Or if one of the other plugins is also applied that configure the

main

distribution, you could then also simply create another

distribution

that you configure how you need it and automatically get the according tasks created.

@Vampire Thanks for the suggestion! Do you know if there's a "clean" way to avoid that the default

distTar

task is being registered by the Distribution plugin? I don't need the tar archive and it feels "wasteful" to have that task automatically being executed when

assemble

is being executed.

Just set it to disabled?

I was hoping that I was missing a setting which would control whether the task was being registered to begin with, but disabling it will definitely work, too. Thanks!