Idiomatic gradle for adding archive to 'assemble' task?

Help/Discuss
1

What’s the idiomatic way for extending the ‘assemble’ task to also build a ‘test-jar’ archive?

I wrote my own ‘test-jar’ plugin, which introduces a new Configuration ‘testArchives’. Although Configuration extends Buildable, it seems not possible to make the ‘assemble’ task depend on the Configuration. I have to make it dependent on the Jar task, which creates the archive.

Wouldn’t it be preferrable to express the relationships based on input/output artifacts instead of raw task dependencies?

// the explicit Java-like style of this code is intentional
class TestJarPlugin implements Plugin<Project> {
    static String CONFIGURATION_NAME = 'testArchives'
    static String CLASSIFIER = 'tests'
    static String TASK_NAME = 'testJar'

    @Override
    void apply(final Project prj) {
        prj.with {
            apply plugin: JavaPlugin.class

            JavaPluginConvention javaPluginConvention = convention.getPlugin(JavaPluginConvention.class)
            SourceSet sourceSet = javaPluginConvention.sourceSets[SourceSet.TEST_SOURCE_SET_NAME]

            Jar testJarTask = task(type: Jar, group: BasePlugin.BUILD_GROUP, dependsOn: sourceSet.output, TASK_NAME)
            testJarTask.classifier = CLASSIFIER
            testJarTask.from sourceSet.output

            Configuration testArchivesConfiguration = configurations.create(CONFIGURATION_NAME)
            artifacts.add testArchivesConfiguration.name, testJarTask
            
            // doesn't work
            //tasks.getByName(BasePlugin.ASSEMBLE_TASK_NAME).dependsOn testArchivesConfiguration
            tasks.getByName(BasePlugin.ASSEMBLE_TASK_NAME).dependsOn testJarTask
        }
    }
}
2

Looks like the way to go is:

tasks.getByName(BasePlugin.ASSEMBLE_TASK_NAME).dependsOn testArchivesConfiguration.artifacts

What’s conceptually the difference between the two Buildables

  • testArchivesConfiguration
  • testArchivesConfiguration.artifacts?

Thanks and regards

3

The former refers to dependencies. Specifically, the Buildable will represent task dependencies responsible for creating any project dependencies added to that configuration.

The latter is specifically referring to artifacts that have been explicitly added to that configuration.

In a way we are using Configuration to be a container for two different things here.