Registering a directory type variant backed by a custom copy task

Help/Discuss
1

For our cross version integration tests we used to rely on our packaged archives that we unzip before we run our tests.
I migrated this unpacking to be done via artifact transforms requesting by directory type variant of the dependency.
That works great so far, but now when I wanna test the current version of my distribution I don’t download the distribution from anywhere
but build it locally.
By changing the providing subproject (the one that builds the distribution) to provide an unpacked version of my distribution in the first place
I wanna safe the unnecessary packing / unpacking cycle. The problem is, that I don’t know how to do that without internal classes.

My current approach looks like this:

def creatingDirTask = tasks.register('directoryDistributionCreatedTask', Copy)

Configuration configuration = configurations.getByName("default")
ConfigurationPublications publications = configuration.getOutgoing();
ConfigurationVariantInternal variant = (ConfigurationVariantInternal) publications.getVariants().maybeCreate("directory");
variant.getAttributes().attribute(ArtifactAttributes.ARTIFACT_FORMAT, ArtifactTypeDefinition.DIRECTORY_TYPE);
variant.artifactsProvider(new Factory<List<PublishArtifact>>() {
    @Override
    List<PublishArtifact> create() {
        List<PublishArtifact> artifacts = new ArrayList<>();

        artifacts.add(new AbstractPublishArtifact(buildCopyTask) {
            @Override
            String getName() {
                return creatingDirTask.name
            }

            @Override
            String getExtension() {
                return ""
            }

            @Override
            String getType() {
                return ArtifactTypeDefinition.DIRECTORY_TYPE;
            }

            @Override
            String getClassifier() {
                return null
            }

            @Override
            File getFile() {
                return creatingDirTask.get().getOutputs().getFiles().getSingleFile();
            }

            @Override
            Date getDate() {
                return null
            }

            @Override
            boolean shouldBePublished() {
                return false
            }
        });
        return artifacts;
    }
})

as you can see there are a bunch of internal classes there. Is there a more idiomatic way to achieve what I’m looking for?

2

Given the radio silence I assume there’s no public api way of doing that at the moment.

3

I’d approach this a slightly different way, I’d have a flag which determines where to get the classes from (eg the unpacked zip or a local project) then I’d declare the dependency differently based on the flag

apply plugin: 'java'

def creatingDirTask = tasks.register('directoryDistributionCreatedTask', Copy)
creatingDirTask.configure {
   // configure the task which downloads & unpacks to a directory
}

boolean useLocalProject = 'true'.equalsIgnoreCase(project.findProperty('useLocalProject'))
dependencies {
   compile(useLocalProject ? project(':local-project') : files(creatingDirTask))
}
4

There’s also DependencySubstitutions which might do this a bit more elegantly

5

Hey Lance,
thanks for your reply. Meanwhile I changed the implementation slightly on our side a bit to use a different providing configuration for the explodedDist distribution. that way I think I get away with not requiring a variant definition at all and make the distinction on the consuming side. Ideally though that would not be required. We package multiple distributions in different suprojects to be able to do this safely in parallel.

BTW. DependencySubstitutions come with some limitations which were a deal breaker for us in the past.

6

FYI: I changed the providing project to expose the exploded dist in a separate configuration. That way I do not rely on the internal variant stuff as shown in my snippet above

7

I’m guessing it’s the same principal as my solution (ie the client decides which configuration to use based on a flag)

8

Yeah basically it does. Though in my original version the client also decided which one to use by requesting a certain variant. It’s just now a bit more explicit which is fine in our case.