How do I publish an artifact with a configurable file name from a custom task that is not an AbstractArchiveTask?

(David Nelson) #1

I am writing a custom task that essentially post-processes the result of the standard jar task. I also have a plugin that creates an instance of that task, as well as a custom configuration. Now I want to add the output of my custom task as an artifact of my custom configuration. The problem is that, just like the standard jar task, the output file name of the task is dynamic; it may change during project configuration. But the ArtifactHandler does not provide any way to specify a dynamic file name as an artifact. The standard jar task can get around this because ArtifactHandler special cases the AbstractArchiveTask, so that the output of such tasks that have been added as artifacts is read during execution instead of configuration. But since my task is not an AbstractArchiveTask, it cannot use that functionality.

It seems to me that instead of special casing AbstractArchiveTask, the ArtifactHandler should simply allow any task to be added to a configuration’s artifacts, and read the outputs.files of that task during execution.

The only workaround I have found is to use afterEvaluate in my plugin to add the artifact after the project has been configured. But that is extremely brittle (what if the project removes or alters the default task during configuration?), and also does not give the project the option of removing the artifact during configuration. Is there a better way to achieve this?

(Tye Howard) #2

Have you tried making your task of type “AbstractArchiveTask”? Depending on what you are trying to do, it may be a bit of a hack, but it should provide you with the dynamic artifact determination you are trying to achieve.

(David Nelson) #3

That seems like an awful hack. I think I would have to replace all of the actions on task to make it work? And it would leave me with a bunch of properties on my task that I don’t actually use.

Shouldn’t there be a more supported mechanism for declaring artifacts whose names are not known until execution time?

(Luke Daley) #4

If you add the artifact as a file ( you can change the name afterwards by accessing it via:

DefaultPublishArtifact artifact = configurations.archives.artifacts.find { == "some-name" } = "new name"

Yes, it should be easier. It will be with the new publication mechanism that is actively in progress.

(Scott Palmer) #5

I am using the newer maven-publish plugin and the ‘townsfolk’ gradle-release plugin. I noticed that when the release plugin removes -SNAPSHOT from my project version that it didn’t update the names used for Jar files. So I added a step to change the name used by the jar files:

confirmReleaseVersion << {

println “Setting artifact versions to ${project.version}”

jar.version = project.version

javadocJar.version = project.version

schemaZip.version = project.version


this works to create the jar files with the correct version number in the name. However, unlike the behavior mentioned above, the publishing task is NOT smart about evaluating the Jar filenames during execution. It attempts to publish with the old name containing the -SNAPSHOT in the version.

How can I work around this? I tried to ‘reconfigure’ the publishing but got an error: > Cannot configure the ‘publishing’ extension after it has been accessed.

(Scott Palmer) #6

What if the archive file was used as the INPUT to a custom task? E.g. I obfuscate the jar produced by the jar task. The “release” plugin changes the filename produced by the jar task and therefore the input to the obfuscate task must change… but tasks have already started, so I get a deprecation warning.