The Gradle module

Access Warden Gradle

me.darksidecode.accesswarden.gradle

This module is a simple Gradle plugin that wraps the Core module. With this module, instead of manually transforming your build application JARs each time you release a new version, Access Warden will do its job automatically whenever the Gradle jar task is has ran (after it has finished, to be precise). This means that all you'll have to do is basically update your code to start using Access Warden annotations (such as @RestrictedAccess) and rebuild your application — you don't have to do any java -jar access-warden-core or anything like that.

Usage

First, apply the access-warden-gradle plugin to your Gradle build script:

buildscript {
    repositories {
        maven {
            name 'Public Reflex Repository'
            url 'https://archiva.reflex.rip/repository/public/'
        }
    }

    dependencies {
        classpath "me.darksidecode.accesswarden.gradle:access-warden-gradle:1.0.0"
    }
}

apply plugin: 'me.darksidecode.access-warden-gradle'

// other stuff like "... group: 'my.company.myapp' ..."

Second, add this line somewhere near the end of your Gradle build script:

jar.finalizedBy accessWardenGradle

That's it! You can now just build your application, and Access Warden will do all the magic automatically.

Don't forget to include the API module in implementation (runtime) dependencies, though — everything in Access Warden is based on its API module. See this page for details on including the API module in your project.

Build File Deduction

The Access Warden Gradle plugin does not know the exact location of your application output JAR. It deducts it. (This is because I haven't found a proper way to detect final JAR file path programmatically in a Gradle plugin.) The deduction algorithm attempts to read and transform JARs in the order specified below (top priority highest):

1. project-name-all.jar (fat-jar/uber-jar without version).
2. project-name-all-x.y.z.jar (fat-jar/uber-jar with version).
3. project-name.jar (ordinary jar without version).
4. project-name-x.y.z.jar (ordinary jar with version).

Fat-jars/uber-jars (JAR files with all the necessary dependencies compiled) have higher priority because they are much likely to be distributed. Files without version numbers have higher priority because these JARs are usually formed with special Gradle tasks, and hence are also much likely to be distributed.

Note that the project version does not have to be semantic. It can be any string. Access Warden Gradle basically just grabs its value from your build.gradle build script.

If some of the tested JARs (again, the order is top-to-bottom) was successfully found, read, transformed, and saved, then the process will exit — the accessWarden Gradle task will complete. Otherwise, the next JAR (below in the priority list) will be tested, until no more candidate JARs are left. In any case, the accessWarden Gradle task should never complete with an error — so it's strongly recommended to keep an eye on Gradle build log for warnings/errors.