Custom Plug-in for AWS Lambda packaging

Help/Discuss
1

We use Gradle to package java projects for execution on AWS Lambda using AWS’s “zip” method - dependent libraries are copied into a lib sub-directory in the zip file.

This is fairly simple to do by adding the following to build.gradle for the projects that need to be packaged this way:

task buildZip(type: Zip) {

    archiveVersion = ""

    from compileJava
    from processResources
    into('lib') {
        from(configurations.runtimeClasspath)
        fileMode 420 // -rw-r--r--
    }
}
build.dependsOn buildZip

However, this results in copy-pasting of this solution into many different projects.

I would like to add this functionality to a gradle plug-in, so something simple like:

plugins {
    id 'org.abc.lambdapackaging' version '0.0.1'
}

could be used.

I’d also like to preserve some of the existing configurability of the Zip task, for example allow users of the lambda packing plug in to decide whether to keep the archive version.

After reading the Gradle plug-in development documentation, I think I will need a plug-in that adds a custom task that extends the standard Zip task, provides some “sensible” defaults (primarily the pattern of files needed in the zip as dictated by aws lambda), but still allows the normal Zip task extension configuration to be applied over the top of my defaults. Or maybe I can just include a task based on Zip with “sensible” defaults (as per my example above) but still have the ability for the user to override them on a case by case basis.

Using the Gradle plug-in documentation, I can write simple (Java rather than Groovy) plug-ins with custom tasks, but I’m stumped on how to extend an existing task and still support the existing tasks extension properties, maybe in addition to properties I’d like to add for the new task.

In a custom plug in, how can I go about added an “extended” version of an existing task (i.e. Zip) while preserving the existing tasks extension properties?

Open to other suggestions if there is a better way to solve this problem. In some cases we’ve gradle included common scripts across several projects, but I think the ideal solution is a custom plug-in hosted on the Gradle Plugin Portal.