This module is a simple Gradle plugin that wraps theCore 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 Gradlejar 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 usingAccess Warden annotations (such as@RestrictedAccess) and rebuild your application — you don't have to do anyjava -jar access-warden-core or anything like that.

First, apply theaccess-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"    }}applyplugin:'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, andAccess Warden will do all the magic automatically.

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

TheAccess Warden Gradle plugin does not know the exact location of your application output JAR. Itdeducts it. (This is because I haven't found a proper way to detectfinal 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-jarwithout version).
2. project-name-all-x.y.z.jar (fat-jar/uber-jarwith version).
3. project-name.jar (ordinary jarwithout version).
4. project-name-x.y.z.jar (ordinary jarwith 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 doesnot have to besemantic. It can beany string.Access Warden Gradle basically just grabs its value from yourbuild.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 — theaccessWarden 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, theaccessWarden Gradle task should never complete with an error — so it's strongly recommended tokeep an eye on Gradle build log for warnings/errors.