Has anyone considered publishing a set of standardized “profiles” for the Java plugin? I spent a couple of days working on busting up Java projects into multiple configurations and artifacts.
Check out what I’ve done so far: java.profile.gradle. This will modify existing configurations & tasks, create 4 new configurations (sources, main, tests, & docs) for 5 new archives (6 total: source, classes, & javadoc for each of main & test source sets).
Archives tasks
--------------
jar - Assembles a jar archive containing the main classes. [classes]
jarTest - Assembles a jar archive containing the test classes. [testClasses]
zipJavadoc - Assembles a zip archive containing the main Javadoc. [javadoc]
zipSources - Assembles a jar archive containing the main source files.
zipTestJavadoc - Assembles a zip archive containing the Javadoc API documentation for the test source code. [testJavadoc]
zipTestSources - Assembles a jar archive containing the test source files.
Build tasks
-----------
assemble - Assembles all Jar, War, Zip, and Tar archives. [jar, jarTest, zipJavadoc, zipSources, zipTestJavadoc, zipTestSources]
Documentation tasks
-------------------
javadoc - Generates Javadoc API documentation for the main source code. [classes]
testJavadoc - Assembles a zip archive containing the Javadoc API documentation for the main source code. [classes, jarTest, testClas
ses]
This script isn’t perfect (as witnessed by the “TODO” I can’t figure out), but I like it quite a bit. The idea is to modularize your module by creating configurations for specific purposes. When other people depend on a module, they should be able to depend on one or more configurations of that module without being coupled with specific artifacts or getting a bunch of stuff they don’t want. I’d love your feedback on what I’ve done so far.
What occurred to me is that there must be several other well known “profiles” like this out there for defining everything from configurations & artifacts to overriding the default Java conventions for source sets, dists, etc. What would be nice is if there was a repository where some of the more popular (and well tested) ones exist for people to pull from. Maybe it would save the next guy/gal 2 days creating 88 lines of mostly trival Gradle. I’ve read the Gradle cookbook, but it seems a little outdated and not the right place for something like this.